# Indexer un catalogue WooCommerce de 150 000 produits dans Algolia sans timeout

> Comment découper l'indexation d'un catalogue massif pour Algolia sans bloquer le serveur, avec une file d'attente et une synchronisation incrémentale.

- Auteur : WordPress Développement
- Publié le : 2023-11-22
- Mis à jour le : 2023-11-22
- Catégorie : E-commerce
- URL : https://www.wpmoderne.fr/ecommerce/indexer-catalogue-150000-produits-algolia-sans-timeout/

## L’essentiel

- L'indexation complète se découpe en lots via Action Scheduler, jamais en une seule tâche
- Seuls les produits modifiés depuis la dernière synchronisation repartent vers Algolia
- Un webhook Algolia confirme la fin de traitement de chaque lot avant d'enchaîner

Cent cinquante mille produits. C'est la taille du catalogue d'un site d'agence spécialisé dans le mobilier professionnel, avec un nombre de références qui rendait toute tentative d'indexation complète en une seule requête vouée à l'échec : timeout serveur systématique au-delà de dix minutes d'exécution, quelle que soit la configuration PHP côté hébergement.

L'extension officielle Algolia pour WooCommerce propose une indexation complète en un clic, pensée pour des catalogues de quelques milliers de références. Au-delà d'un certain volume, cette approche synchrone sature la mémoire PHP allouée et dépasse la limite de temps d'exécution, avant même d'avoir traité un dixième du catalogue.

## Découper en lots via Action Scheduler

La première décision d'architecture a été d'abandonner l'indexation en un bloc au profit d'un découpage en lots de 500 produits, chacun traité par une tâche Action Scheduler distincte, plutôt que par une seule tâche cron longue. Ce choix permet à chaque tâche de rester sous la limite de temps d'exécution PHP, tout en laissant WordPress répartir la charge sur plusieurs exécutions successives, avec un traitement en arrière-plan qui ne bloque jamais une requête utilisateur.

```
function planifier_indexation_algolia( $offset = 0, $taille_lot = 500 ) {
    as_schedule_single_action(
        time() + 10,
        'indexer_lot_algolia',
        array( 'offset' => $offset, 'taille' => $taille_lot ),
        'algolia-index'
    );
}

add_action( 'indexer_lot_algolia', function( $offset, $taille ) {
    $produits = wc_get_products( array( 'limit' => $taille, 'offset' => $offset, 'status' => 'publish' ) );
    if ( empty( $produits ) ) {
        return; // Fin de l'indexation complète.
    }
    algolia_indexer->index_batch( $produits );
    planifier_indexation_algolia( $offset + $taille, $taille );
} );
```

## Synchronisation incrémentale plutôt que complète

> L'essentiel à retenir : L'indexation complète se découpe en lots via Action Scheduler, jamais en une seule tâche ; Seuls les produits modifiés depuis la dernière synchronisation repartent vers Algolia ; Un webhook Algolia confirme la fin de traitement de chaque lot avant d'enchaîner

Une fois l'indexation initiale terminée, réindexer l'intégralité des 150 000 produits à chaque modification de catalogue aurait été absurde. La synchronisation courante repose sur un déclenchement ciblé, accroché à `woocommerce_update_product` et `woocommerce_update_product_stock`, qui met en file d'attente uniquement le produit modifié, avec un délai de regroupement de trente secondes pour absorber les mises à jour en rafale (import massif, changement de prix en lot) sans multiplier les appels API vers Algolia.

Ce regroupement s'appuie sur une meta transitoire, `_algolia_sync_pending`, posée à la première modification détectée et retirée une fois le lot traité, évitant qu'un même produit modifié dix fois en une minute ne déclenche dix appels API distincts.

## Confirmer la fin de traitement avant d'enchaîner

Le point qui a le plus retardé la mise au point : sans confirmation de traitement effectif côté Algolia, la file d'attente locale pouvait considérer un lot comme traité alors que l'API Algolia l'avait mis en file d'attente de son côté sans encore l'avoir indexé, provoquant des incohérences temporaires entre l'affichage front (résultats de recherche) et l'état réel du catalogue.

La solution a consisté à s'appuyer sur l'identifiant de tâche (`taskID`) renvoyé par chaque appel d'indexation Algolia, puis à interroger l'endpoint de statut de tâche avant de considérer un lot comme définitivement traité et de déclencher le lot suivant :

- Envoi du lot de 500 produits à Algolia, récupération du `taskID`.
- Vérification du statut via l'endpoint de suivi de tâche, avec une tentative répétée espacée de quelques secondes.
- Passage au lot suivant seulement après confirmation du statut « publié » côté Algolia.
- Journalisation de chaque lot avec son `taskID`, pour permettre un diagnostic a posteriori en cas d'écart constaté.

> Conseil maison : sur un très gros catalogue, ne considérez jamais un envoi API réussi comme une indexation terminée. Un appel qui répond « accepté » n'est pas la même chose qu'un appel dont le résultat est effectivement disponible côté moteur de recherche.

## En résumé

Indexer 150 000 produits WooCommerce dans Algolia sans timeout suppose d'abandonner l'indexation synchrone en bloc au profit d'un découpage en lots pilotés par Action Scheduler, complété par une synchronisation incrémentale ciblée sur les seuls produits modifiés. La configuration du widget de recherche front, avec ses filtres et son tri par pertinence, reste un chantier séparé de cette architecture d'indexation.