# Tester la recherche d’un catalogue B2B avec Elasticsearch dans DDEV

> Comment prototyper une recherche à facettes sur un catalogue industriel sans toucher à la production ? Un service Elasticsearch ajouté à DDEV pour tester avant de déployer.

- Auteur : WordPress Développement
- Publié le : 2021-03-22
- Mis à jour le : 2021-03-22
- Catégorie : Outils &amp; workflow
- URL : https://www.wpmoderne.fr/outils/tester-elasticsearch-catalogue-b2b-ddev/

## L’essentiel

- Service Elasticsearch déclaré via un fichier docker-compose additionnel de DDEV
- Indexation du catalogue B2B depuis une commande wp-cli personnalisée
- Facettes de recherche testées localement avant tout choix d'hébergement managé

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.

> L'essentiel à retenir : Service Elasticsearch déclaré via un fichier docker-compose additionnel de DDEV ; Indexation du catalogue B2B depuis une commande wp-cli personnalisée ; Facettes de recherche testées localement avant tout choix d'hébergement managé

```
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.
