Elasticsearch sur PrestaShop : quand la recherche produit devient le problème

Un visiteur tape trois lettres dans votre barre de recherche. Il attend. Cinq secondes. Huit. Parfois dix. Sur mobile, dans le train, il est déjà parti.

Ce scénario n’a rien d’exceptionnel : c’est le comportement normal de la recherche native de PrestaShop dès que le catalogue dépasse quelques dizaines de milliers de références. Le moteur n’est pas cassé, il fait exactement ce pour quoi il a été conçu. Il n’a simplement pas été conçu pour cette taille.

Cet article raconte ce qu’on fait à ce moment-là. Comment on diagnostique le décrochage, pourquoi Elasticsearch règle le problème, ce que ça coûte réellement, et les trois usages qu’on en a tirés sur deux boutiques de 30 000 produits : la recherche, l’affichage des listings, et depuis peu un assistant produit fondé sur un modèle de langage.

La recherche native de PrestaShop décroche pour une raison structurelle, pas par manque d’optimisation. Elle repose sur des tables d’index qui gonflent avec le produit du nombre de références par le nombre de déclinaisons, et sur des recherches textuelles que la base de données ne peut pas indexer efficacement. À 30 000 produits avec des déclinaisons, on passe de la lenteur à l’indisponibilité.

Elasticsearch n’est pas une barre de recherche, c’est une couche d’accès au catalogue. Sur nos deux intégrations, il sert la recherche, mais aussi les pages catégorie et les filtres à facettes. C’est là que se joue l’essentiel du gain, et c’est ce que la plupart des présentations du sujet passent sous silence.

Le même index alimente désormais un assistant produit. Un moteur de recherche bien construit est aussi la source de données dont un modèle de langage a besoin pour répondre correctement. C’est le chantier sur lequel nous sommes en ce moment, et nous en parlons plus bas sans en faire une promesse.

PrestaShop maintient ses propres tables d’index de recherche. À chaque enregistrement de produit, le moteur découpe les textes en mots et alimente ces tables, qui associent chaque mot aux produits où il apparaît. Le principe est sain, et il fonctionne très bien sur un catalogue de quelques centaines ou quelques milliers de références.

Trois choses se dégradent ensemble quand le catalogue grossit.

Le volume de la table d’index explose. Elle ne croît pas avec le nombre de produits, mais avec le nombre de produits multiplié par la richesse textuelle de chacun : nom, descriptions, attributs, caractéristiques, marque. Sur un catalogue mode où chaque modèle existe en huit tailles et six coloris, la combinatoire des déclinaisons fait le reste.

Les requêtes deviennent des jointures lourdes. Pour produire une page de résultats, la base doit croiser l’index de recherche, les produits, leurs déclinaisons, leurs attributs, leurs stocks, leurs prix, leurs catégories et leurs images. Chaque jointure supplémentaire coûte, et ce coût n’est pas linéaire.

La recherche partielle n’est pas indexable. Chercher un mot où qu’il se trouve dans un texte oblige la base à parcourir séquentiellement, sans pouvoir s’appuyer sur ses index. C’est la différence entre chercher un mot dans l’index d’un livre et lire le livre en entier. À faible volume, personne ne le remarque. À 30 000 fiches, la lecture prend dix secondes.

Le symptôme apparaît d’abord sur la recherche, parce que c’est là que les requêtes sont les plus coûteuses. Mais il ne reste pas confiné.

Sur les deux boutiques, les pages catégorie étaient touchées elles aussi. C’est logique : afficher une liste filtrée de produits mobilise les mêmes jointures, avec en plus le calcul des facettes, c’est-à-dire le décompte du nombre de produits restants pour chaque valeur de chaque filtre. Ce calcul doit être refait à chaque changement de sélection.

Le stade suivant, nous l’avons vu : le serveur qui tombe. Des requêtes longues qui s’empilent, un pic de trafic, et la base ne rend plus la main. La boutique renvoie alors une erreur serveur, avec toutes les conséquences que ça implique. Si c’est votre situation actuelle, notre guide de diagnostic des erreurs 500 traite la panne elle-même ; le présent article traite la cause.

Une recherche interne lente n’est donc pas seulement un inconfort de navigation. C’est un facteur de fragilité de l’ensemble de la boutique, et personne ne le formule comme ça parce que le lien de cause à effet n’est pas visible depuis le back-office.

Elasticsearch est un moteur de recherche qui tourne sur son propre serveur, à côté de votre boutique. On lui envoie une copie du catalogue sous une forme qu’il sait interroger très vite, et la boutique vient lui poser des questions au lieu de les poser à sa base de données.

La différence tient à la structure. Une base de données relationnelle est organisée pour garantir l’intégrité des données : une commande ne peut pas exister sans client, un stock ne peut pas être négatif. Cette rigueur a un coût quand il s’agit de fouiller du texte. Un moteur de recherche, lui, est organisé pour répondre vite à la question « où apparaît ce mot », au prix d’une copie des données et d’un décalage de quelques secondes avec la source.

Ce compromis est exactement le bon pour un catalogue produit. Vous n’avez pas besoin que la liste des résultats soit juste à la milliseconde près. Vous avez besoin qu’elle s’affiche avant que le visiteur ne parte.

Point à connaître si la question de l’indépendance vous préoccupe : Elastic a ajouté en septembre 2024 la licence AGPLv3 aux options de licence d’Elasticsearch, ce qui referme le débat ouvert en 2021 sur le caractère open source du projet. Vous pouvez l’installer sur vos propres serveurs, sans abonnement, sans dépendance à un éditeur.

C’est le gain le plus spectaculaire et le plus facile à mesurer. Sur nos deux intégrations, une recherche qui demandait cinq à dix secondes au moteur natif s’exécute désormais en moins d’une seconde, catalogue de 30 000 références inclus.

Ce que le natif ne savait pas faire et que l’index permet : encaisser une faute de frappe sans renvoyer une page vide, traiter les synonymes métier — le vocabulaire du client n’est jamais celui du catalogue —, chercher sur une référence constructeur aussi bien que sur un nom commercial, et proposer une autocomplétion qui affiche des résultats pendant la frappe plutôt qu’après validation.

Un effet secondaire mérite d’être signalé, parce qu’il concerne vos équipes autant que vos clients : la recherche produit du back-office bénéficie du même traitement. Sur un catalogue de cette taille, une gestionnaire qui cherche une référence dix fois par jour récupère un temps qui ne se voit sur aucun tableau de bord mais qui compte.

C’est la partie la plus intéressante techniquement, et la plus rentable en pratique. Vos pages catégorie reçoivent beaucoup plus de visiteurs que votre barre de recherche. Accélérer la recherche seule, c’est optimiser une porte que peu de gens empruntent.

Sur nos deux boutiques, nous avons donc remplacé le module de filtres natif de PrestaShop par un module développé sur mesure. Le principe : la boutique interroge Elasticsearch, qui renvoie un JSON contenant les produits correspondants et les décomptes de facettes, et PrestaShop utilise ce JSON pour générer sa page. Les requêtes SQL lourdes disparaissent du chemin critique.

Une précision d’honnêteté, parce qu’elle compte. Ce module ne fait rien que le natif ne savait pas faire fonctionnellement. Les filtres ne sont pas plus riches, les critères pas plus nombreux. Ce qui change, c’est uniquement la vitesse — et la capacité à encaisser la croissance du catalogue sans que la situation ne se dégrade à nouveau. Si quelqu’un vous vend Elasticsearch en promettant des fonctionnalités inédites côté filtres, demandez-lui lesquelles précisément.

Un catalogue bien indexé est aussi ce dont un modèle de langage a besoin pour répondre correctement. C’est le constat qui nous a menés au troisième usage.

Le montage : un modèle Llama installé sur un VPS que nous administrons, connecté à l’index Elasticsearch de la boutique. Un visiteur pose une question en langage naturel sur un produit ou une catégorie. Le système va chercher dans l’index les fiches pertinentes, les transmet au modèle, et le modèle formule une réponse à partir de ces fiches uniquement. C’est le principe du RAG, la génération augmentée par la récupération : le modèle ne répond pas de mémoire, il répond à partir de votre catalogue.

Ce qui est indexé pour alimenter les réponses : nom du produit, prix, caractéristiques, attributs, marque, description courte, description longue, image. Autrement dit, la qualité des réponses dépend directement de la qualité de vos fiches produit. Une boutique aux descriptifs indigents obtiendra un assistant indigent, et aucune technologie ne comblera ce trou.

L’état réel du chantier. Le dispositif fonctionne, il n’est pas encore en production. Deux difficultés : le modèle est lourd à faire tourner, et il demande un cadrage sérieux pour rester dans les clous du catalogue plutôt que de broder. La latence est perceptible, acceptable pour une consultation, pas encore pour un usage à la volée. Nous sommes en phase de finalisation et il passera vraisemblablement en production.

Nous en parlons parce que c’est la direction que prend la recherche e-commerce, et parce que le prérequis est justement celui décrit dans cet article : sans index structuré, pas d’assistant fiable. Si le sujet de l’IA appliquée à vos outils métier vous intéresse au-delà du catalogue, c’est le terrain de notre accompagnement en automatisation.

Cette section décrit le fonctionnement concret de nos intégrations. Si vous êtes dirigeant et que les termes qui suivent ne vous parlent pas, sautez-la : la section suivante reprend au niveau des coûts et des arbitrages.

Un serveur dédié, jamais mutualisé. Elasticsearch tourne sur un VPS distinct de la boutique, avec sa mémoire propre. Le dialogue se fait par API. Une installation sur un hébergement mutualisé n’a aucun sens : le moteur réclame de la RAM en continu et un contrôle du processus que ces offres n’accordent pas.

Une double stratégie de synchronisation. Une réindexation complète du catalogue s’exécute chaque nuit — trente minutes environ pour 30 000 produits. Elle sert de filet de sécurité : quoi qu’il se soit passé dans la journée, l’index repart propre. En complément, un module sur mesure accroche les hooks produit de PrestaShop et pousse les mises à jour à l’unité dès qu’une donnée change. Le stock et le prix, qui bougent en permanence, passent par ce canal. Un produit tombé en rupture disparaît des listings sans attendre la nuit.

Un JSON en sortie, pas une page. Elasticsearch renvoie les produits et les décomptes de facettes sous forme de JSON. C’est PrestaShop qui construit la page à partir de ces données. Le thème, les templates et le fonctionnement du back-office restent inchangés : on remplace la source des données, pas l’affichage. C’est ce qui rend l’intervention réversible.

Un repli automatique sur le natif. Si le serveur Elasticsearch ne répond plus, le module bascule sur la recherche native de PrestaShop. La boutique redevient lente, elle ne devient pas inutilisable. C’est le point à exiger de quiconque vous propose ce type d’intégration : sans repli, vous avez déplacé votre point de défaillance unique, vous ne l’avez pas supprimé.

Deux à trois semaines de développement pour l’ensemble — module d’indexation, hooks de synchronisation, remplacement des facettes, recette. La durée dépend surtout de l’état du thème existant et du nombre d’attributs à cartographier.

Algolia est la référence du marché en solution hébergée. C’est excellent, c’est rapide, et c’est aussi une dépendance : vos données de catalogue partent chez un tiers, la facturation suit le volume de requêtes, et le jour où vous voulez modifier le comportement du moteur, vous faites avec ce qui est prévu. Nous ne l’avons pas retenu pour cette raison, pas pour une raison technique. Sur des projets où l’équipe cliente n’a aucune compétence d’exploitation et veut zéro serveur à gérer, l’arbitrage peut basculer dans l’autre sens.

Les modules de recherche du marché coûtent quelques centaines d’euros et améliorent réellement le natif. Ils restent moins performants sur les gros volumes, parce que la plupart continuent de s’appuyer sur la base de données. En dessous de quelques milliers de références, ils suffisent souvent. Au-delà, ils repoussent le mur sans le supprimer.

Meilisearch et Typesense sont des moteurs plus légers, réputés plus simples à exploiter, et régulièrement cités comme des alternatives crédibles sur des catalogues de taille moyenne. Nous ne les avons pas mis en œuvre et nous ne porterons pas de jugement sur ce que nous n’avons pas éprouvé en production.

OpenSearch, né du fork d’Elasticsearch par AWS en 2021 et placé sous gouvernance de la Linux Foundation en 2024, est très proche fonctionnellement. Le débat de licence qui justifiait historiquement de le préférer s’est en grande partie éteint avec le retour d’Elasticsearch sous licence open source.

Sur le fond, un moteur de recherche externe n’est jamais un mauvais investissement : une fois le système en place, il absorbe la croissance du catalogue sans plafond visible. Passer de 30 000 à 100 000 références ne change pas l’architecture, seulement la taille de l’index.

Mais le critère de décision n’est pas la taille du catalogue, c’est le ressenti mesuré. Si vos pages catégorie s’affichent rapidement, si vos facettes répondent instantanément et si votre recherche rend la main en moins d’une seconde, vous n’avez rien à gagner. Ajouter un serveur, un flux de synchronisation et un module sur mesure à une boutique qui va bien, c’est ajouter trois choses qui peuvent tomber en panne pour résoudre un problème que vous n’avez pas.

Avant d’engager le chantier, vérifiez aussi que le ralentissement n’a pas une cause plus simple : un hébergement sous-dimensionné, un cache mal configuré, un module tiers qui plombe chaque chargement de page. Un moteur de recherche externe n’effacera pas ces problèmes, il les masquera pendant quelques mois.

La bonne séquence est donc : mesurer, identifier la cause, et seulement ensuite décider. C’est ce que nous faisons en audit, et il nous arrive de conclure que le sujet est ailleurs.