DDEV et Meilisearch en local : indexer sans dépendre d’un service externe

ddev describe affiche la liste des services actifs d’un projet local : base de données, serveur web, et parfois un service ajouté à la main. C’est ce dernier point qui rend DDEV intéressant pour tester une recherche instantanée sans dépendre d’un compte chez un fournisseur externe — en ajoutant Meilisearch comme service additionnel du projet.

Une équipe qui prépare une recherche à facettes pour un catalogue de produits n’a pas toujours besoin, au stade du prototype, de créer un compte sur un service hébergé et d’y envoyer de vraies données. Faire tourner Meilisearch localement, à l’intérieur de l’environnement DDEV existant, permet d’itérer sur la pertinence des résultats et le réglage des attributs de recherche avant de décider d’un déploiement en production.

Ajouter Meilisearch comme service additionnel DDEV

DDEV permet de déclarer des services supplémentaires en déposant un fichier docker-compose.*.yaml dans le dossier .ddev du projet. Ce fichier étend la configuration générée automatiquement par DDEV sans avoir à toucher au fichier principal .ddev/config.yaml.

# .ddev/docker-compose.meilisearch.yaml
version: '3.6'
services:
  meilisearch:
    container_name: ddev-${DDEV_SITENAME}-meilisearch
    image: getmeili/meilisearch:v0.17.0
    restart: "no"
    environment:
      - MEILI_MASTER_KEY=cledeveloppementlocal
      - MEILI_ENV=development
    labels:
      com.ddev.site-name: ${DDEV_SITENAME}
      com.ddev.approot: ${DDEV_APPROOT}
    volumes:
      - ".:/mnt/ddev_config"

Après un ddev restart, le conteneur meilisearch rejoint automatiquement le réseau du projet. Il devient joignable depuis le conteneur web à l’adresse http://meilisearch:7700, sans exposer de port ni de service public sur le poste de développement.

Vérifier que le service répond avant d’indexer

Une fois le conteneur démarré, une requête simple confirme que l’API Meilisearch répond correctement depuis l’intérieur de l’environnement DDEV :

• ddev ssh pour entrer dans le conteneur web du projet
• curl http://meilisearch:7700/health pour vérifier l’état du service
• curl -H "Authorization: Bearer cledeveloppementlocal" http://meilisearch:7700/indexes pour lister les index existants

Indexer le catalogue depuis une commande WP-CLI

Le pont entre WordPress et Meilisearch se fait le plus simplement via une commande WP-CLI personnalisée qui boucle sur les produits et pousse chaque document vers l’API. Pas besoin d’extension tierce à ce stade du prototype : quelques appels HTTP suffisent depuis PHP avec wp_remote_post().

$produits = get_posts( array(
    'post_type'   => 'product',
    'numberposts' => -1,
) );

$documents = array();
foreach ( $produits as $produit ) {
    $documents[] = array(
        'id'          => $produit->ID,
        'titre'       => $produit->post_title,
        'description' => wp_strip_all_tags( $produit->post_content ),
        'categorie'   => wp_get_post_terms( $produit->ID, 'product_cat', array( 'fields' => 'names' ) ),
    );
}

wp_remote_post( 'http://meilisearch:7700/indexes/produits/documents', array(
    'headers' => array(
        'Authorization' => 'Bearer cledeveloppementlocal',
        'Content-Type'  => 'application/json',
    ),
    'body' => wp_json_encode( $documents ),
) );

L’intérêt de cette approche est immédiat pour l’équipe : chaque développeur dispose de son propre index Meilisearch, isolé dans son environnement DDEV, sans risquer de polluer un index partagé pendant les phases de test sur la pertinence des résultats.

Régler la pertinence sans quitter le poste local

Meilisearch expose un point d’entrée pour ajuster les attributs recherchés et les attributs de tri, ce qui permet de tester différents réglages de pertinence directement depuis le prototype local. Modifier l’ordre des attributs recherchés dans attributesForSearching et relancer une recherche donne un retour immédiat, sans latence réseau vers un service distant.

Tester la pertinence en local avant de choisir un hébergement définitif évite de payer un service géré pendant toute la phase de réglage, qui est souvent la plus longue.

Ce que cette approche ne couvre pas

Ce service Meilisearch local ne synchronise rien vers une instance de production : c’est un choix assumé. La bascule vers un déploiement réel demande une réflexion séparée sur l’hébergement du moteur de recherche, la sécurisation de la clé d’API et la mise à jour incrémentale de l’index à chaque modification de produit, autant de sujets qui dépassent le cadre d’un prototype local.

En résumé

Ajouter Meilisearch comme service DDEV coûte un seul fichier de configuration et quelques minutes de mise en route, pour un gain réel : tester une recherche instantanée sur un vrai catalogue sans dépendance externe ni risque sur les données. Cette approche convient parfaitement à la phase de prototype ; le déploiement en production reste un chantier à part entière, avec ses propres choix d’hébergement et de sécurité.