Moteur de recherche interne : Elasticsearch, Solr et bonnes pratiques de pertinence

Table des matières :

Elasticsearch vs Solr : critères concrets pour un moteur de recherche interne e-commerce

Choisir un moteur de recherche interne ne se résume pas à « prendre du Lucene ». Elasticsearch et Solr reposent tous les deux sur Apache Lucene, mais leurs compromis d’architecture, d’exploitation et de gouvernance n’ont rien d’équivalent. Elasticsearch (8.x en 2026 dans la majorité des stacks auto-hébergées) pousse un modèle orienté API JSON/REST, des agrégations très pratiques, une observabilité souvent plus simple à brancher, et un écosystème outillé (Beats/Agent, Kibana, etc.). Solr (9.x) reste extrêmement solide sur des schémas explicites, des pipelines d’analyse très contrôlables, et une culture « search platform » plus proche des équipes IR historiques.

Côté licence et gouvernance, il faut être lucide : Solr est sous licence Apache 2.0, Elasticsearch n’est plus sous Apache 2.0 depuis plusieurs années (licences Elastic). Pour un SI qui vise un maximum de neutralité (et/ou des redistributions), Solr a un avantage net. À l’inverse, si votre équipe veut accélérer sur un protocole et des patterns standardisés (JSON DSL, index templates, aliases, ILM), Elasticsearch reste souvent plus « rapide à industrialiser ».

Pour prendre une décision moins “religieuse” et plus exploitable en comité projet, vous pouvez cadrer quelques critères concrets (ceux qui, en e-commerce, finissent par coûter du temps/argent) :

Critère	Elasticsearch	Solr
Gouvernance / neutralité	Dépend des licences Elastic	Apache 2.0, très “neutre”
Modélisation	Mapping JSON, dynamique possible (à éviter en prod)	Schéma explicite, très contrôlé
Requêtage	DSL JSON riche, très répandu	Paramètres (edismax) + JSON Request API
Facettes	Agrégations ergonomiques	JSON Facet API très mature
Ops & observabilité	Écosystème “Elastic Stack” intégré	Très robuste aussi, mais plus “assemble-it-yourself”
Équipe	Souvent plus facile à prendre en main côté dev web	Souvent plus familier côté équipes IR/search historiques
Stratégie d’évolution	Aliases + templates + ILM (pratique)	Collections + configsets + swap/alias (efficace)

Côté projet (pas uniquement côté moteur), un point souvent sous-estimé est la gouvernance des règles de pertinence : qui a le droit de changer les boosts ? qui valide un changement de synonymes ? quelle cadence de reindexation est acceptable ? Sur un site e-commerce FR (RGPD, logs, équipes marketing/merchandising), la dimension “process” pèse parfois plus que la techno : un Solr très bien schématisé ou un Elasticsearch très bien template-isé échoueront pareil si tout le monde peut “tuner” en prod sans tests.

Dans PrestaShop, la bascule depuis la recherche cœur (SQL + index interne) doit être motivée par un besoin mesurable : volume catalogue, latence, pertinence, autocomplétion, facettes temps réel, merchandising, multi-langue, ou logs de recherche exploitables. Avant de partir sur ES/Solr, gardez une base de comparaison claire avec le comportement natif : Index de recherche PrestaShop : fonctionnement, tables SQL et pondérations permet de cadrer ce que vous perdez (simplicité) et ce que vous gagnez (contrôle fin de la pertinence).

Mini-scenario réaliste (souvent rencontré sur des catalogues B2C en France) : vous passez de 20 000 à 120 000 produits (déclinaisons incluses), et la recherche SQL devient acceptable “à froid” mais très instable aux pics (soldes, Black Friday). Les facettes prix/marque explosent en latence, l’autocomplétion finit par être coupée “temporairement”, et l’équipe marketing commence à demander des règles du type “pousser la collection été” ou “déclasser le hors stock”. À ce stade, ES/Solr n’est pas un luxe : c’est une manière de rendre la recherche pilotable.

Modéliser l’index : mapping, analyzers, multilingue et champs “métier”

Un moteur de recherche interne performant commence par un modèle d’indexation assumé. Dans Elasticsearch, cela passe par un mapping strict (types, normalizers, analyzers) et des champs multi-variantes : name.fr, name.en, name.folded, reference.keyword, category_path, etc. Dans Solr, vous exprimerez les mêmes intentions via schema.xml/managed schema, fieldType + chaines d’analyse, et souvent des champs dynamiques (*_t_fr, *_s, *_i). Le point dur n’est pas le JSON ou le XML : c’est de décider quelles informations doivent contribuer au score (texte), lesquelles doivent filtrer (keyword), lesquelles doivent agréger (facettes), et lesquelles doivent servir à des boosts business.

Sur la partie « analyse » (tokenization), évitez l’approximation. Un index e-commerce en français doit gérer : accents (folding), apostrophes (élision), pluriels/stemming, stopwords, mais aussi les références produit et SKU (où le stemming est destructeur). Typiquement, on sépare :

champs text analysés pour la recherche (title, description_short, attributes_text),
champs keyword/non analysés pour les filtres et exact match (brand, reference, ean13),
champs search_as_you_type / edge n-gram (ES) ou EdgeNGramFilterFactory (Solr) pour l’autocomplétion.

Deux détails “terrain” qui font une vraie différence sur des boutiques FR :

Élisions et apostrophes : l'huile, d'entretien, aujourd'hui. Si votre analyse découpe mal, vous perdez en rappel sur des requêtes très fréquentes.
Formats de référence : AB-123, AB123, ab 123. Sans normalisation (suppression de tirets/espaces + lowercasing), vous aurez des “zéro résultat” artificiels alors que le produit existe.

Une méthode simple pour cadrer vos champs (et éviter l’index “fourre-tout”) consiste à classer chaque attribut en 4 catégories :

Search (scoring) : doit influencer le ranking (ex. nom produit, marque en champ de scoring, catégorie).
Filter : doit filtrer sans analyser (ex. marque, disponibilité, gamme, compatibilité).
Facet/Aggregation : doit agréger efficacement (ex. prix, marque, attributs normalisés, catégories).
Display : nécessaire au rendu (ex. image principale, URL, prix courant, labels), sans influencer le score.

Pour le multilingue, deux stratégies dominent : (1) un index par langue (plus simple pour la pertinence, plus cher à opérer), (2) un index unique avec champs par langue et un routing de requête selon la langue du shop (moins coûteux, mais mapping plus lourd). Dans PrestaShop 8.1/9 (PHP 8.2/8.3), la langue est un axe fonctionnel majeur (URLs, slugs, contenus). Si votre projet touche aussi la génération de slugs et métadonnées, la brique search doit rester cohérente avec la stratégie de localisation SEO (voir : Traduction PrestaShop : localisation SEO automatique hreflang, slugs et métadonnées).

Enfin, pensez “métier” dès le mapping : la recherche interne n’est pas un moteur neutre. Exemples de champs très utiles à long terme (et faciles à regretter si vous ne les indexez pas) : stock_status (instock / preorder / outof_stock), sales_30d, is_new, margin_bucket, supplier_delay_days, return_rate_bucket, shipping_class. Même si vous ne boostez pas tout de suite dessus, les avoir disponibles permet d’itérer sans réarchitecture.

Pertinence : BM25, boosts, synonymes et scoring “business”

En 2026, la plupart des implémentations « naïves » tombent dans le même piège : compter sur le ranking par défaut sans expliciter la pertinence. Lucene utilise BM25 comme base ; la documentation Lucene le formule explicitement : “Lucene’s default similarity implementation is BM25Similarity.” (Apache Lucene Javadocs, BM25Similarity : documentation Lucene core). Traduction opérationnelle : votre score sera dominé par la fréquence de terme, la longueur du champ, et l’IDF — ce qui n’intègre pas vos signaux e-commerce (stock, marge, popularité, nouveauté).

La bonne pratique consiste à découpler :

1) une requête textuelle robuste (multi-champs, fuzziness contrôlée, synonymes),

2) un re-ranking / function score sur signaux métier.

Dans Elasticsearch, le pattern standard est multi_match + function_score (ou script_score si vous acceptez le coût CPU). Dans Solr, c’est edismax avec qf (query fields), pf (phrase boosts), bf (boost functions) et boost/bq (boost queries). Exemple typique : booster le champ name x5, category x2, description_short x1, puis ajouter un boost doux basé sur log1p(sales_30d) et pénaliser les produits hors stock.

Deux garde-fous pratiques pour éviter un scoring “magique” impossible à maintenir :

Gardez des boosts lisibles : des ordres de grandeur simples (x2, x5, x10) et des fonctions monotones (log, sqrt), plutôt que des formules qui deviennent ésotériques après 3 mois.
Séparez ce qui relève de l’IR et du merchandising : l’IR doit répondre à “de quoi parle la requête ?”, le merchandising à “quoi pousser à pertinence comparable ?”. Mélanger les deux dès le premier score crée des surprises (un produit hors-sujet qui remonte car “très vendu”).

Les synonymes et règles de merchandising doivent être traités comme du code : versionnés, testés, déployés. Les synonymes « larges » (ex. “iphone” ↔ “smartphone”) dégradent vite la précision. Préférez : synonymes de marques, d’abréviations, de fautes récurrentes, et vocabulaire métier (ex. “SSD” ↔ “disque ssd”). Sur Elasticsearch, utilisez des synonym graphs quand vous faites des requêtes en phrase ; sur Solr, privilégiez SynonymGraphFilterFactory dans une chaîne dédiée. Et surtout : documentez où vous appliquez les synonymes (index-time vs query-time), car index-time impose une réindexation à chaque changement.

Astuce “qualité” très rentable : maintenez une petite liste de requêtes sensibles (marques stratégiques, catégories phares, top requêtes sans clic) et validez-les automatiquement à chaque changement de synonymes/boosts. Même sans framework complexe, un tableau “requête → top 5 attendu” évite des régressions évidentes (ex. un synonyme qui fait remonter des accessoires avant les produits principaux).

Fonctionnalités e-commerce : autocomplétion, tolérance aux fautes, facettes, “zéro résultat”

Une recherche interne e-commerce n’est pas un moteur documentaire. L’autocomplétion (« search-as-you-type ») doit être rapide (< 50–80 ms côté API) et tolérante aux fautes sans devenir permissive. C’est un sujet à part entière : edge n-grams, champs dédiés, poids par type de suggestion (produit vs catégorie vs marque), et stratégies anti-bruit (min length, stopwords, blocage des tokens trop fréquents). Si vous êtes en PrestaShop, il est utile de cadrer l’UX et les impacts de perf avant de câbler ES/Solr : Recherche interne PrestaShop : optimiser suggestions live et tolérance aux fautes donne une grille de lecture des compromis.

Un point souvent négligé : l’autocomplétion n’a pas forcément le même modèle que la recherche. Beaucoup d’équipes obtiennent de meilleurs résultats en séparant :

un index “produits” pour la recherche complète (richesse, facettes),
un index “suggest” (ou des champs dédiés) optimisé pour des prefixes, avec des poids (popularité, disponibilité, catégories à pousser).

Les facettes (prix, marques, attributs, disponibilité) sont souvent la première raison technique de sortir de la recherche SQL. Côté ES, les agrégations (terms, range, histogram) sont très ergonomiques ; côté Solr, les facettes sont historiques et extrêmement performantes (JSON Facet API). Dans les deux cas, l’erreur fréquente est d’agréger sur des champs mal typés (text au lieu de keyword/string) et de faire exploser la cardinalité (ex. facetter sur un champ libre). Sur un catalogue avec beaucoup de déclinaisons, séparez bien le document “produit” du document “offre/variant” ou vous allez facetter sur des champs instables.

Checklist rapide “facettes qui tiennent en prod” :

facetter sur des champs normalisés (ex. brand_id ou brand.keyword, pas un champ texte libre),
limiter la taille (size) des facettes marques/attributs et trier par count,
pour le prix, préférer des ranges cohérents avec votre UX (ex. paliers fixes) plutôt qu’un histogramme trop fin,
éviter de calculer des facettes sur un jeu de résultats minuscule si votre UX s’attend à “voir l’offre globale” (question de design : facettes globales vs facettes dépendantes).

Enfin, gérez le “zéro résultat” comme un événement produit, pas comme un échec silencieux. Une recherche qui retourne 0 est un signal d’intention non couverte : synonymes manquants, index incomplet, ou contenu absent. Mesurez systématiquement : taux de zéro résultat, CTR sur résultats, taux d’ajout panier après recherche. En PrestaShop, vous avez un cadre de KPI et d’exploitation : Recherche interne PrestaShop : mesurer CTR, zéro résultat et conversion (même si vous n’utilisez pas le moteur natif).

Tactiques simples et efficaces sur “zéro résultat” (sans trahir l’intention utilisateur) :

proposer une correction orthographique (si disponible) et des suggestions de marques/catégories,
relâcher progressivement (ex. enlever la fuzziness sur les références, relâcher sur la description seulement, retirer un filtre trop strict),
afficher les requêtes proches (ex. tee shirt vs t-shirt, brosse a dents vs brosse à dents), particulièrement utile en FR où accents/tirets varient.

Pipeline d’indexation depuis PrestaShop : cohérence, mises à jour delta, et rollback

Le moteur de recherche interne doit être alimenté par des données cohérentes. Dans PrestaShop, la base MySQL/MariaDB reste la source de vérité (produits, déclinaisons, prix spécifiques, stock, règles panier). Si votre SQL est déjà limite (requêtes lentes, schémas qui dérivent, index manquants), vous allez indexer du “sale” plus vite, pas mieux. Avant d’industrialiser ES/Solr, mettez au carré la couche data : Développeur MySQL : optimiser requêtes, schémas et performances en production et Requêtes MySQL lentes PrestaShop : activer slow query log sont des prérequis pragmatiques.

Sur le pipeline, évitez l’indexation synchrone “dans le hook” : c’est la recette pour faire du checkout une victime collatérale. Pattern recommandé :

hooks PrestaShop → événements “domaine” (product updated, stock changed, price changed),
enqueue dans une queue (Redis streams, RabbitMQ, SQS… selon votre infra),
workers d’indexation idempotents,
indexation en bulk (batch) + retry + dead letter queue.

Vous aurez une cohérence éventuelle (acceptable si vous la mesurez) et vous protégerez les endpoints critiques. Si vous utilisez Redis comme brique d’infra, faites-le proprement (ACL, persistance, monitoring) : Redis sur Linux : installation, configuration et sécurisation production.

Deux points d’attention très e-commerce (où “prix” et “stock” bougent plus vite que le contenu) :

Mises à jour delta : indexer le descriptif produit toutes les minutes n’a aucun sens si le flux critique est “stock” et “prix”. Séparez les événements et, si besoin, maintenez un document qui supporte des updates partiels (ou une stratégie de “partial update”/atomic update selon le moteur).
Groupes client / prix spécifiques : si votre boutique a des prix différents par groupe, vous ne pourrez pas tout pré-calculer dans l’index sans explosion combinatoire. Une stratégie fréquente est d’indexer un prix “public” + des drapeaux (promo active, prix barré, etc.) et de finaliser certains calculs côté application.

Le rollback est le point que tout le monde ignore jusqu’au jour où une règle de mapping casse l’index. En Elasticsearch, utilisez des aliases : products_current pointe vers products_v42, vous réindexez vers products_v43, puis vous switcher l’alias (opération quasi instantanée). En Solr, utilisez des collections versionnées + swap (ou alias selon votre mode). Dans les deux cas : ne “modifiez” pas un analyzer en prod en espérant que ça passe ; un changement d’analyse impose généralement une réindexation complète. Pour encadrer les versions et la compatibilité applicative, gardez une checklist similaire à une migration : les mêmes réflexes que pour Migration PrestaShop 9 : sécurité, tests et plan de rollback s’appliquent (staging, tests, fenêtres de tir, et plan de retour arrière).

Pratique simple à adopter : indexez un champ indexed_at et/ou un data_version (hash ou timestamp métier). Cela vous aide à diagnostiquer rapidement si un bug vient de la recherche (requête/scoring) ou de l’alimentation (document obsolète).

Exploiter les logs et tester la pertinence : du feeling à l’évaluation mesurable

La pertinence ne se “configure” pas une fois. Elle se pilote comme un produit : on collecte, on évalue, on itère. À minima, loggez chaque requête avec : query string, filtres, langue, nombre de hits, top N IDs retournés, clics, add-to-cart, et conversion. Sur Elasticsearch, vous pouvez activer les slow logs de recherche et indexation et exporter vers votre stack d’observabilité ; sur Solr, exploitez le request logging + métriques Dropwizard. Et ne mélangez pas logs applicatifs et logs search : ce sont deux plans différents (latence API vs qualité de ranking).

Dans un contexte France/UE, gardez en tête que les logs de recherche peuvent devenir des données personnelles si vous loggez des identifiants, des emails, ou des requêtes “libres” contenant des informations sensibles. Appliquez les mêmes règles que pour n’importe quel tracking : minimisation, durée de conservation, accès restreint, et pseudonymisation si vous bucketisez par session.

Pour sortir du subjectif, adoptez des métriques IR. Sur un set de requêtes (top 500/2000) avec jugements (relevant/non relevant ou gradés), calculez MRR@k (utile pour le top-1), NDCG@k (pour le top-10), Recall@k (pour vérifier que vous ne cassez pas la couverture). Ensuite seulement, vous jouez sur : champs, boosts, synonymes, fuzziness, rules. Beaucoup d’équipes e-commerce découvrent que 80% du gain vient de 20% de requêtes (marques, catégories, top produits).

Table “à garder sous la main” pour aligner technique et métier :

KPI / métrique	Ce que ça détecte	Risque si vous l’ignorez
p95 latence recherche	coûts infra, requêtes trop lourdes	UX dégradée, surtout mobile
Taux de zéro résultat	trous de catalogue, analyse/synonymes	pertes de conversion invisibles
CTR post-search	attractivité des premiers résultats	“bon recall” mais mauvais ranking
Conversion post-search	qualité business réelle	optimisation “vanity metrics”
NDCG@10 (offline)	qualité de ranking globale	régressions silencieuses

En production, reliez explicitement les changements de ranking à des impacts business, sinon vous allez “optimiser” à l’aveugle. Un exemple réaliste : une modification de fuzziness peut augmenter le CTR mais baisser la conversion (plus de faux positifs). Gardez un A/B test simple (bucket par session) et mesurez : latence p95, CTR search, taux de zéro résultat, conversion post-search, et revenu par session. Ce type de discipline est aligné avec la logique d’audit qualité avant publication : Audit SEO technique : contrôle qualité avant publication des pages web (mêmes réflexes de contrôle, mais appliqués à la recherche interne).

Prérequis infra, performance et sécurité : ce que le cœur PrestaShop ne gère pas pour vous

Elasticsearch et Solr sont des services stateful qui n’aiment pas l’approximation infra. Sizing minimal : CPU dédié, RAM pour heap (Solr/ES sont JVM), disque rapide (NVMe si possible), I/O stable, et sauvegardes testées. Les “petits” clusters sous-dimensionnés finissent en latence erratique (GC, merges, IO wait). Sur ES, surveillez heap, pressure, segment merges et refresh ; sur Solr, surveillez caches, merges et GC. Si vous êtes en phase de prérequis, alignez-vous aussi sur les compatibilités : Exigences système : compatibilités PHP, MariaDB et Elasticsearch minimales (même si votre code PHP n’exécute pas ES, votre stack globale doit rester cohérente).

Quelques repères opérationnels (simples mais utiles) :

Heap JVM : classique recommandation “pratique” en prod : dimensionner la heap pour laisser de la RAM à l’OS (cache filesystem), et éviter de pousser la heap trop haut sans raison (GC et pauses).
Disque : la recherche écrit beaucoup (segments, merges). Une latence disque instable se voit immédiatement sur la p95.
Shards/collections : trop de shards/segments = overhead permanent ; trop peu = reindex et scaling difficiles. Visez une granularité qui correspond à votre croissance (catalogue, langues, boutiques).

Sur la performance applicative, cherchez la latence bout-en-bout : navigateur → PrestaShop → moteur → rendu. Même avec un ES parfait, si votre front fait des appels bloquants multiples ou si votre serveur PHP est déjà sous pression, vous n’atteindrez pas un ressenti rapide. Travaillez le cache (résultats de facettes “chaudes”, suggestions), et définissez ce qui peut être mis en cache sans casser la personnalisation (prix client, disponibilité par entrepôt, etc.). Pour les caches serveur autour de PrestaShop (Varnish/Redis/OPcache), gardez une vue d’ensemble : Cache PrestaShop : Varnish, Redis, Memcached et OPcache côté serveur.

Sur la sécurité, n’exposez jamais un cluster search “ouvert” sur Internet. Activez TLS, authentification, et filtrage réseau (security groups, firewall). Côté reverse proxy, le rate limiting est utile pour éviter qu’un bot ne transforme votre recherche interne en DoS applicatif (autocomplétion = endpoint idéal pour ça). Un HAProxy bien configuré (TLS termination, rate limiting, métriques) fait le job : HAProxy reverse proxy : terminaison TLS, rate limiting et supervision Prometheus. Et si vous servez des assets lourds (JS de search UI, fonts, etc.), un CDN n’améliore pas la pertinence, mais il stabilise l’expérience : CDN en 2026 : comparatif Bunny.net, Cloudflare, Akamai, CloudFront, Fastly.

Quand ES/Solr n’est pas le bon choix : cadrer les alternatives sans dogme

Elasticsearch et Solr ne sont pas les seuls moteurs viables. Si votre besoin principal est la recherche interne “simple” avec un time-to-market court, un moteur comme Meilisearch peut être plus pragmatique (setup rapide, API simple, features e-commerce classiques). L’intérêt n’est pas de « remplacer Algolia » par principe, mais d’adapter l’outil au niveau d’exigence (pertinence, SLA, ops). Pour élargir le comparatif, gardez sous la main : Alternatives à Algolia 2026 : 7 solutions de recherche site web et, côté mise en œuvre PrestaShop, un exemple concret : Recherche interne PrestaShop : intégrer Meilisearch pour booster la conversion.

Le vrai critère est la capacité de votre équipe à maintenir la pertinence dans le temps. Solr/ES donnent de la puissance, mais exigent une discipline d’indexation, des tests, de l’observabilité, et une approche produit (synonymes, règles, KPI). Si vous n’avez pas ces fondations, vous allez “tuner” au feeling, réindexer en urgence, et créer de la dette.

Qui “possède” la recherche ? (dev, produit, merchandising, data) et qui arbitre les conflits (pertinence vs marge vs stock) ?
Quel est votre budget d’exploitation ? (monitoring, sauvegardes, upgrades, incidents). Un moteur gratuit peut coûter cher en astreinte.
Quel est votre besoin de contrôle fin ? Si vous avez besoin de modèles avancés (segmentation, règles, signaux) et d’une gouvernance stricte, ES/Solr se justifient. Sinon, une solution plus simple peut mieux servir le business.

Enfin, si votre architecture e-commerce évolue vers du headless ou des microservices, le moteur de recherche interne devient souvent un service dédié, avec son propre cycle de déploiement, ses propres SLIs, et son propre modèle de données. À ce moment-là, la question n’est plus “ES ou Solr”, mais “comment je versionne le schéma, comment je synchronise, comment je mesure l’impact”. Pour cadrer ce type de décision, une grille d’arbitrage architecture est utile : Architecture backend : monolithe moderne ou microservices, critères décisionnels.