Comment tester une recherche à facettes sur un catalogue industriel de plusieurs milliers de références sans jamais toucher à l’index de production ni s’engager auprès d’un service hébergé avant d’avoir validé la pertinence des résultats ? La réponse retenue pour ce projet a consisté à ajouter Elasticsearch comme service additionnel à l’environnement DDEV du projet, pour prototyper entièrement en local.
Le catalogue en question comptait environ sept mille références réparties sur plusieurs familles de produits industriels, chacune avec des attributs techniques différents (dimensions, matière, norme de conformité) qui devaient devenir des facettes de recherche. Avant de choisir un hébergement Elasticsearch managé, coûteux à l’usage, l’équipe a préféré valider d’abord la pertinence de l’approche sur un environnement local complet.
Déclarer Elasticsearch comme service DDEV
DDEV permet d’étendre sa configuration générée automatiquement via un fichier docker-compose.*.yaml placé dans le dossier .ddev du projet, sans modifier la configuration principale. C’est cette mécanique qui permet d’ajouter un service Elasticsearch sans sortir du cadre de DDEV pour le reste du projet.
# .ddev/docker-compose.elasticsearch.yaml
version: '3.6'
services:
elasticsearch:
container_name: ddev-${DDEV_SITENAME}-elasticsearch
image: docker.elastic.co/elasticsearch/elasticsearch:7.10.1
restart: "no"
environment:
- discovery.type=single-node
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
labels:
com.ddev.site-name: ${DDEV_SITENAME}
com.ddev.approot: ${DDEV_APPROOT}
Après un ddev restart, le service devient accessible depuis le conteneur web du projet à l’adresse http://elasticsearch:9200, joignable uniquement à l’intérieur du réseau DDEV du projet, sans exposition publique.
Définir le mapping avant d’indexer
Contrairement à une base de données classique, Elasticsearch bénéficie d’un mapping explicite qui décrit le type de chaque champ, en particulier pour les champs destinés à devenir des facettes de recherche : un champ de type keyword permet un filtrage exact, quand un champ de type text se prête à une recherche en texte libre. Sur un catalogue industriel, la distinction compte : la norme de conformité d’un produit doit être filtrable exactement, alors que sa description doit rester cherchable en texte libre.
curl -X PUT "http://elasticsearch:9200/catalogue_b2b" -H 'Content-Type: application/json' -d'
{
"mappings": {
"properties": {
"reference": { "type": "keyword" },
"titre": { "type": "text" },
"description":{ "type": "text" },
"norme": { "type": "keyword" },
"matiere": { "type": "keyword" },
"prix_ht": { "type": "float" }
}
}
}'
Indexer le catalogue depuis WP-CLI
Une commande wp-cli personnalisée boucle sur les produits du catalogue (des articles d’un type de contenu personnalisé produit-industriel) et pousse chaque document vers l’API Elasticsearch locale via wp_remote_post(), sans dépendance à une extension tierce à ce stade du prototype.
$produits = get_posts( array(
'post_type' => 'produit-industriel',
'numberposts' => -1,
) );
foreach ( $produits as $produit ) {
wp_remote_request( "http://elasticsearch:9200/catalogue_b2b/_doc/{$produit->ID}", array(
'method' => 'PUT',
'headers' => array( 'Content-Type' => 'application/json' ),
'body' => wp_json_encode( array(
'reference' => get_post_meta( $produit->ID, 'reference', true ),
'titre' => $produit->post_title,
'norme' => get_post_meta( $produit->ID, 'norme', true ),
'matiere' => get_post_meta( $produit->ID, 'matiere', true ),
) ),
) );
}
Tester les facettes avant tout engagement
Une fois l’index alimenté, des agrégations Elasticsearch permettent de tester directement le rendu des facettes attendues (norme, matière, plage de prix) sans avoir écrit la moindre ligne d’interface front. Ce test a permis de découvrir, avant tout déploiement, que certaines valeurs de matière saisies de façon incohérente dans les fiches produits existantes (des variantes d’orthographe pour la même matière) auraient pollué les facettes une fois en production.
- Vérification de la pertinence des facettes sur le jeu de données réel
- Détection des incohérences de saisie avant la mise en production
- Validation de l’architecture de recherche avant de choisir un hébergement définitif
Un prototype de recherche testé sur le vrai volume de données révèle des problèmes de qualité de contenu qu’aucune démonstration sur un jeu de données restreint ne fait apparaître.
Ce que cette approche ne couvre pas
Le déploiement d’Elasticsearch en version managée, avec ses questions de dimensionnement de cluster, de sécurité d’accès et de sauvegarde des index, reste un chantier entièrement distinct de ce prototype local. Ce test en environnement DDEV n’a vocation qu’à valider l’approche avant d’engager les coûts d’un service managé en production.
En résumé
Ajouter Elasticsearch comme service DDEV a permis de valider en quelques jours la pertinence d’une recherche à facettes sur un catalogue de sept mille références, et surtout de détecter des incohérences de saisie dans le contenu existant avant qu’elles ne deviennent visibles en production. Cette phase de test local, peu coûteuse, a évité de s’engager directement sur un service managé sans certitude sur la qualité réelle des données à indexer.
