Algolia plutôt que la recherche native : indexer 100 000 contenus WordPress

wp_insert_post se déclenche cent mille fois par jour sur un catalogue de ce volume, entre les mises à jour de stock, les changements de prix et les corrections de fiches par l’équipe éditoriale. Réindexer l’intégralité du catalogue vers Algolia à chaque déclenchement de ce hook ferait exploser le quota d’opérations d’indexation en quelques heures, sans compter le temps de traitement bloquant côté serveur.

Ce tutoriel construit une synchronisation incrémentale : seuls les objets réellement modifiés partent vers Algolia, regroupés en lots, avec un mécanisme de rattrapage pour les cas où une mise à jour aurait échoué silencieusement. Il ne traite pas la comparaison avec Meilisearch, qui fait l’objet d’un article séparé et davantage centré sur le choix entre les deux moteurs.

Mettre en file plutôt qu’envoyer directement

La première erreur commune consiste à appeler l’API Algolia directement depuis le hook save_post, ce qui rend chaque sauvegarde d’article dépendante de la disponibilité du service tiers. La bonne pratique consiste à empiler l’identifiant du contenu modifié dans une file, traitée ensuite en tâche de fond via Action Scheduler :

add_action( 'save_post_produit', function ( $post_id, $post, $update ) {
    if ( wp_is_post_revision( $post_id ) ) {
        return;
    }

    as_enqueue_async_action(
        'wpm_algolia_indexer_objet',
        array( 'post_id' => $post_id ),
        'wpm-algolia'
    );
}, 10, 3 );

Ce découplage garantit que l’éditeur qui enregistre une fiche produit ne subit aucun ralentissement lié à la latence réseau d’Algolia, même en cas de pic de trafic sur l’API du moteur de recherche.

Regrouper les objets en lots

L’API Algolia accepte un envoi groupé via l’endpoint /1/indexes/*/batch, ce qui réduit drastiquement le nombre de requêtes HTTP par rapport à un envoi objet par objet. La tâche planifiée traite les identifiants en file par paquets, plutôt qu’un par un :

function wpm_algolia_traiter_lot( array $post_ids ) : void {
    $objets = array();

    foreach ( array_slice( $post_ids, 0, 1000 ) as $post_id ) {
        $post = get_post( $post_id );
        if ( ! $post || 'publish' !== $post->post_status ) {
            continue;
        }

        $objets[] = array(
            'objectID' => (string) $post_id,
            'titre'    => get_the_title( $post_id ),
            'prix'     => (float) get_post_meta( $post_id, '_prix', true ),
            'contenu'  => wp_strip_all_tags( $post->post_content ),
        );
    }

    if ( ! empty( $objets ) ) {
        wpm_algolia_index()->saveObjects( $objets );
    }
}

Le rattrapage par réconciliation

Aucune file n’est fiable à cent pour cent : un timeout réseau, un dépassement de quota temporaire ou un redémarrage de worker peut faire disparaître une tâche sans qu’elle soit rejouée. Une tâche planifiée nocturne compare le nombre d’objets présents dans l’index Algolia à celui des fiches publiées côté WordPress, et réindexe les écarts détectés :

add_action( 'wpm_algolia_reconciliation_quotidienne', function () {
    $ids_wp = get_posts( array(
        'post_type'      => 'produit',
        'post_status'    => 'publish',
        'fields'         => 'ids',
        'posts_per_page' => -1,
    ) );

    $ids_algolia = wpm_algolia_lister_object_ids();
    $manquants   = array_diff( $ids_wp, $ids_algolia );

    foreach ( array_chunk( $manquants, 1000 ) as $lot ) {
        as_enqueue_async_action( 'wpm_algolia_traiter_lot', array( 'post_ids' => $lot ) );
    }
} );

Points de vigilance sur un gros catalogue

• Les suppressions doivent déclencher un deleteObject() explicite via le hook before_delete_post, pas seulement une absence de mise à jour.
• Les variations de stock à haute fréquence (rupture, retour en stock) méritent un objet Algolia allégé, mis à jour via partialUpdateObjects() plutôt qu’un saveObjects() complet.
• La taille de chaque objet compte dans le quota de facturation Algolia : exclure les champs non recherchables du contenu indexé, comme les descriptions longues déjà résumées ailleurs.

Sur ce type de projet, la métrique qu’on surveille en priorité n’est pas le temps de réponse d’Algolia — il est excellent par construction — mais le délai entre une modification WordPress et sa visibilité réelle dans les résultats de recherche.

Pour aller plus loin

Une synchronisation incrémentale bien construite transforme un problème d’échelle en simple question de configuration : taille des lots, fréquence de réconciliation, granularité des mises à jour partielles. Le piège à éviter reste la tentation du renvoi complet « pour être sûr », qui semble rassurant mais qui, sur cent mille contenus, finit toujours par saturer le quota d’opérations et par dégrader la fraîcheur réelle de l’index plutôt que de l’améliorer.