Recherche intelligente pour PrestaShop : quand la recherche par défaut ne suffit plus

Comportement natif vérifié avec la classe Search du cœur PrestaShop et les réglages Paramètres de la boutique → Recherche sur 1.7.6+, 8.x et 9.x.

Un client saisit "bycicle helmet" dans votre barre de recherche. Il voulait écrire "bicycle helmet", une lettre inversée. Sur une installation PrestaShop récente, il obtient souvent bien des résultats, car PrestaShop intègre depuis des années une correspondance approximative. Mais activez le mauvais réglage, importez un lourd vocabulaire de synonymes que votre catalogue n’a jamais prévu, ou laissez l’index de recherche se périmer, et ce même client voit une page vide, suppose que vous ne vendez pas de casques, puis s’en va. Vous en aviez 47 en stock. Cet article explique précisément l’écart entre ce que fait réellement la recherche native de PrestaShop, plus que ce qu’imaginent la plupart des marchands, et les limites qu’elle finit vraiment par atteindre.

Cette distinction est importante, parce que le conseil habituel ("la recherche par défaut est stupide, achetez un module de recherche") est à moitié faux et vous coûte de l’argent dans les deux sens. Certaines boutiques perdent des ventes à cause de réglages qu’elles pourraient corriger gratuitement dans le back-office cet après-midi. D’autres ont déjà optimisé tous les leviers natifs et continuent de perdre des visiteurs à forte intention d’achat. Pour elles, un autre moteur est la réponse honnête. Vous ne pouvez savoir dans quel cas vous vous trouvez qu’une fois que vous savez ce que fait vraiment la recherche native.

Ce que fait réellement la recherche native de PrestaShop (plus que vous ne le pensez)

Le champ de recherche du front-office est géré par le SearchController et la classe cœur Search (classes/Search.php). Il ne parcourt pas vos produits avec une recherche naïve en LIKE '%term%'. À la place, à chaque enregistrement de produit, PrestaShop découpe les champs indexables en jetons dans les tables ps_search_word et ps_search_index, puis, au moment de la requête, il cherche dans cet index préconstruit et attribue un score aux résultats. Trois comportements natifs surprennent la plupart des marchands :

• La correspondance approximative (tolérante aux fautes) est intégrée. Le réglage PS_SEARCH_FUZZY permet à PrestaShop de faire correspondre un mot saisi avec un mot indexé malgré une petite distance d’édition. Ainsi "bycicle" peut quand même mener à "bicycle". Vérifiez si la recherche approximative/fuzzy est activée dans Paramètres de la boutique → Recherche. La valeur PS_SEARCH_FUZZY_MAX_LOOP limite l’effort effectué par mot afin que la recherche reste rapide. L’idée selon laquelle PrestaShop renvoie zéro résultat à la moindre faute de frappe est tout simplement dépassée.
• Les synonymes existent déjà, sous un autre nom. PrestaShop les appelle des alias et les stocke dans la table ps_alias. Vous les gérez dans le back-office sous Paramètres de la boutique → Recherche → Alias. Associez "canapé" à "sofa", "baskets" à "sneakers", "télé" à "télévision", et le mot du visiteur est réécrit avec le vôtre avant l’interrogation de l’index.
• La pertinence est pondérée, et ces pondérations vous appartiennent. La même page de préférences de recherche expose un poids pour chaque champ indexé, nom du produit, référence/EAN/MPN, description courte, description longue, nom de catégorie, fabricant, tags, attributs et caractéristiques. Une correspondance dans le nom du produit peut compter bien plus qu’une mention isolée enfouie dans une description, ce qui est exactement ce qui évite à "robe rouge" de faire remonter une boîte à outils rouge avant les vraies robes.

Alors, qu’est-ce que cela signifie pour vous ? Avant de dépenser quoi que ce soit, la première chose à faire est d’ouvrir les préférences de recherche natives et de vérifier que la recherche approximative est activée, que les pondérations des champs ont du sens pour votre catalogue, et que vous avez commencé une liste d’alias. Une part importante des plaintes concernant une "recherche cassée" vient en réalité d’un réglage par défaut jamais configuré, d’une liste d’alias laissée vide ou, très souvent, d’un index obsolète.

La cause la plus fréquente d’une "recherche cassée" : un index obsolète

Comme PrestaShop cherche dans un index préconstruit plutôt que dans votre table produit en direct, toute modification effectuée en dehors d’un enregistrement produit normal peut laisser l’index décrire un catalogue qui n’existe plus. Imports en masse, mises à jour SQL, sauvegardes restaurées, modifications multiboutique ou migration inachevée provoquent tous ce problème. Le symptôme est exaspérant : un produit est clairement en ligne sur sa page, mais une recherche sur son nom exact ne renvoie rien.

La solution consiste à reconstruire l’index. Sur la page Paramètres de la boutique → Recherche, une action "Reconstruire l’index complet" est disponible (ainsi qu’une option "Ajouter les produits manquants à l’index" pour des corrections plus légères). Sur les grands catalogues, lancez-la via la tâche cron plutôt que depuis le navigateur afin d’éviter les expirations de délai.

PrestaShop fournit précisément pour cela un point d’entrée cron d’indexation de recherche. Le bouton de la page Recherche l’appelle avec un indicateur de reconstruction complète ; vous pouvez déclencher la même tâche selon un planning. Les champs du formulaire vous donnent l’URL, la reconstruction complète ajoute &full=1, tandis que le passage plus léger "ajouter les produits manquants" l’omet :

# Full rebuild (use after a bulk import / restore / SQL change)
curl -s "https://yourstore.com/searchcron.php?id_shop=1&token=YOUR_SEARCH_TOKEN&full=1"

# Lighter pass: only index products missing from ps_search_index
curl -s "https://yourstore.com/searchcron.php?id_shop=1&token=YOUR_SEARCH_TOKEN"

Le token est la valeur affichée par PrestaShop à côté des actions d’indexation sur la page des préférences de recherche (n’en inventez pas. Copiez l’URL exacte qu’il vous donne). Intégrez l’appel de reconstruction complète dans votre routine d’import et la catégorie de tickets "la recherche est cassée" liée à un index obsolète disparaît largement.

Faites de la reconstruction d’index une étape standard après chaque import en masse, c’est la correction de recherche la moins chère qui existe, et elle résout directement une grande partie des tickets "ma recherche est cassée".

Là où la recherche native atteint réellement ses limites

Rien de ce qui précède ne rend le moteur natif illimité. Une fois les pondérations configurées, les alias renseignés et l’index maintenu à jour, quatre véritables murs subsistent, et ce sont ceux qu’il vaut la peine de payer pour supprimer.

Cette dernière colonne est le test honnête. Si votre problème se trouve dans la première colonne, vous avez probablement épuisé ce que la configuration peut faire, et une couche de recherche dédiée devient une dépense rationnelle plutôt qu’un luxe.

Note sur les deux fonctionnalités "recherche" de PrestaShop que l’on confond souvent

Il vaut la peine de distinguer deux choses que l’on appelle toutes deux "recherche". La barre de recherche (cet article) répond à une requête saisie, "bicycle helmet", et s’appuie sur la classe cœur Search. La recherche à facettes (le module ps_facetedsearch) est la colonne de filtres à gauche sur les pages catégorie, prix, marque, couleur, taille, pour un client qui parcourt déjà une catégorie et veut affiner. Elles répondent à des besoins différents et vous avez généralement besoin des deux. Si votre vrai problème est d’aider les visiteurs à trier une grande catégorie une fois arrivés dessus, c’est l’article sur les filtres qu’il faut lire, pas celui-ci : voir aider les clients à trouver des produits dans de grands catalogues et les pages catégorie qui convertissent.

Ce qu’ajoute une couche de recherche dédiée, et pourquoi elle se rentabilise

Lorsque vous avez dépassé les capacités de la recherche native, un module de recherche conçu pour cela ne se contente pas de "mieux chercher" dans l’abstrait ; il supprime les quatre murs précis ci-dessus. Les fonctionnalités qui comptent, présentées selon le problème métier que chacune résout :

• Résultats AJAX instantanés pendant la saisie. Une liste déroulante de produits correspondants, avec image, prix et lien cliquable, apparaît avant même que le client termine le mot. C’est la plus grande amélioration perçue de qualité, et elle raccourcit le chemin entre l’intention et la page produit.
• Synonymes gérés au lieu d’alias un par un. Regroupez "canapé = sofa = banquette" une seule fois et chaque variante fonctionne, de sorte qu’un pluriel oublié ou un mot régional ne fasse plus perdre une vente.
• Analytique des recherches sans résultat. Un journal exact des recherches qui n’ont rien renvoyé transforme les recherches perdues en liste d’actions : chaque requête vide correspond soit à un produit à référencer, soit à un synonyme à ajouter, soit à une description à corriger. Ce sont des données de demande que vous ne pouvez obtenir autrement.
• Redirections et routage par motifs. Envoyez une faute connue, un nom de marque ou un mot-clé de campagne directement vers la bonne page. Le routage par motifs gère des familles entières de requêtes avec une seule règle, par exemple, toute taille de type "NxN" comme "800x800" ou "90x90" peut arriver sur votre page de dimensions plutôt que sur un ensemble de résultats maigre.
• Merchandising et boosting. Faites remonter les produits à forte marge, en stock ou saisonniers dans les résultats pour les termes choisis, afin que la recherche vende activement au lieu de simplement lister.

C’est précisément l’écart que notre module MPR Search Revolution est conçu pour combler sur PrestaShop : recherche AJAX en temps réel, groupes de synonymes gérés, tableau de bord analytique qui fait remonter les recherches sans résultat et les requêtes tendance, redirections de termes avec routage par motifs, et boosting produit : le tout configuré depuis le back-office, sans chirurgie du thème ni modification du cœur, pour survivre aux mises à jour. Alors, qu’est-ce que cela signifie pour vous ? Les leviers natifs que vous régleriez autrement à la main (synonymes, pertinence, redirections) deviennent un workflow pilotable, et les recherches que vous perdiez auparavant en silence deviennent une liste mesurable et corrigeable. Nous conservons aussi un simulateur de recherche dans le back-office afin que vous puissiez tester ce qu’une requête donnée renvoie avant vos clients.

Comment décider, un cadre rapide

Parcourez ces étapes dans l’ordre ; arrêtez-vous dès que l’une d’elles résout votre problème.

• La recherche ne renvoie rien pour des produits qui existent clairement ? Reconstruisez l’index (Paramètres de la boutique → Recherche). Faites-en une routine après chaque import.
• Des produits non pertinents passent devant les bons ? Augmentez le poids du nom produit et réduisez celui de la description longue sur la même page.
• Une poignée de synonymes ou de fautes connues échouent ? Ajoutez-les comme alias. Si la liste est courte et stable, les alias natifs suffisent vraiment, inutile de suracheter.
• Vous avez besoin de résultats instantanés, de synonymes évolutifs, de données sur les recherches sans résultat ou de contrôle merchandising ? Ce sont les quatre murs natifs. Ici, une couche de recherche dédiée est le bon choix, pas un ajustement de configuration.

La recherche fait partie d’un ensemble plus large de trouvabilité

La barre de recherche est l’une des trois façons dont un client trouve un produit, et les autres doivent jouer leur rôle pour que la recherche ne porte pas tout le travail. Une structure de catégories solide et un méga-menu clair permettent aux visiteurs d’atteindre ce qu’ils veulent sans rien taper, tandis que les filtres sur page affinent une catégorie une fois qu’ils y sont arrivés. Et comme une part importante et croissante de ces recherches se fait désormais sur téléphone, la liste déroulante au fil de la saisie doit être rapide et utilisable au pouce, voir commerce mobile.

Votre barre de recherche est l’un des emplacements les plus précieux de votre site : chaque personne qui l’utilise vous a déjà dit, avec ses propres mots, exactement ce qu’elle est venue acheter. Les clients qui cherchent ont tendance à convertir à un taux nettement plus élevé que ceux qui se contentent de parcourir. Ils ont une intention, donc une recherche qui échoue revient à laisser partir un visiteur à forte intention d’achat. La bonne nouvelle, c’est que les corrections les moins chères (un index à jour, des pondérations cohérentes, une première liste d’alias) sont gratuites et déjà présentes dans votre back-office. Investissez dans une couche de recherche dédiée seulement une fois les murs natifs atteints, et lorsque vous le faites, laissez-la mériter sa place en vous montrant, chaque jour, exactement quelles recherches vous perdiez auparavant.

Questions fréquentes

La recherche par défaut de PrestaShop gère-t-elle vraiment les fautes de frappe ?

Oui. La correspondance fuzzy (approximative) est intégrée depuis des années et contrôlée par le réglage PS_SEARCH_FUZZY dans Paramètres de la boutique → Recherche. Elle compare un mot de la requête à un mot indexé avec une petite distance d’édition, de sorte que "bycicle" peut quand même mener à "bicycle". L’ancienne affirmation selon laquelle toute faute de frappe renvoie zéro résultat est dépassée ; la cause habituelle d’un vrai zéro résultat sur une faute évidente est une recherche approximative désactivée ou un index obsolète.

Mon produit est en ligne mais une recherche sur son nom exact ne trouve rien, pourquoi ?

Presque toujours à cause d’un index obsolète. PrestaShop cherche dans les tables préconstruites ps_search_word / ps_search_index, pas dans votre table produit en direct ; toute modification de produits hors d’un enregistrement normal, imports en masse, mises à jour SQL, sauvegardes restaurées, migrations, peut donc laisser l’index décrire un catalogue qui ne correspond plus. Reconstruisez l’index depuis la page Recherche (ou via le point d’entrée cron ci-dessus) et le produit réapparaît.

PrestaShop prend-il en charge les synonymes ?

Oui, sous un autre nom : les alias, stockés dans ps_alias et gérés dans Paramètres de la boutique → Recherche → Alias. Associez "canapé" à "sofa", "baskets" à "sneakers", et le mot du visiteur est réécrit avec le vôtre avant l’interrogation de l’index. Ils suffisent vraiment lorsque la liste est courte et stable ; leur limite est que chaque synonyme est une ligne manuelle, ce qui ne passe pas à l’échelle des centaines dont un vrai catalogue finit par avoir besoin.

Pourquoi des produits non pertinents passent-ils devant les bons ?

La pertinence est pondérée, et les pondérations vous appartiennent. La page des préférences de recherche expose un poids par champ indexé, nom, référence, descriptions, catégorie, tags, attributs, caractéristiques. Si une recherche "robe rouge" fait remonter une boîte à outils rouge, augmentez le poids du nom produit et réduisez celui de la description longue afin qu’une correspondance dans le nom compte bien plus qu’une mention isolée dans une description.

Comment savoir quelles recherches ne renvoient rien ?

La recherche native ne journalise pas les requêtes sans résultat de façon exploitable, ce qui explique précisément pourquoi la demande non satisfaite fuit en silence. Capturer ce signal, un journal des recherches qui n’ont rien renvoyé, afin que chacune devienne un produit à référencer, un synonyme à ajouter ou une description à corriger, est l’un des quatre murs qu’une couche de recherche dédiée (comme MPR Search Revolution) supprime. Ce sont des données de demande que vous ne pouvez pas obtenir avec la recherche native seule.

Quelle est la différence entre la barre de recherche et la recherche à facettes ?

Elles ne font pas le même travail. La barre de recherche répond à une requête saisie et s’appuie sur la classe cœur Search (cet article). La recherche à facettes (ps_facetedsearch) est la colonne de filtres à gauche sur les pages catégorie, prix, marque, couleur, taille, pour quelqu’un qui parcourt déjà une catégorie. Vous avez généralement besoin des deux ; si votre vrai problème est de trier une grande catégorie après l’arrivée du client, le sujet est le filtrage, pas cet article.

À lire aussi

• Aider les clients à trouver des produits dans de grands catalogues, le filtrage à facettes, l’autre moitié de la trouvabilité sur site.
• Structure de catégories PrestaShop pour une navigation optimisée SEO, permettre aux visiteurs de parcourir les produits sans rien taper.
• Méga-menu PrestaShop : une navigation qui convertit, un menu clair soulage la barre de recherche.