# Migrer un catalogue de 40 000 références vers WooCommerce sans tout casser

> Un grossiste en pièces détachées voulait basculer son catalogue de 40 000 références en un week-end. Retour sur ce qui a tenu, ce qui a plié, et ce qu'on referait autrement.

- Auteur : Clément Hadrot
- Publié le : 2022-11-30
- Mis à jour le : 2022-11-30
- Catégorie : E-commerce
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ecommerce/migrer-catalogue-40000-references-woocommerce/

## L’essentiel

- L'import CSV natif n'a pas tenu au-delà de quelques milliers de lignes
- WP-CLI et un script par lots ont sauvé le calendrier
- Désactiver la synchronisation Analytics pendant l'import était indispensable

Le client, grossiste en pièces détachées pour l'électroménager, disposait d'un catalogue de 40 000 références sur son ancienne plateforme propriétaire, avec des variations de compatibilité par modèle d'appareil pour une bonne partie d'entre elles. L'objectif annoncé en réunion de cadrage : basculer vers WooCommerce sur un week-end, pour limiter l'interruption de vente à quarante-huit heures. Le chiffre, une fois posé noir sur blanc, a immédiatement changé la façon d'aborder le projet.

La première tentative, avec l'outil d'import CSV natif de WooCommerce, a confirmé une intuition partagée par l'équipe dès le cadrage : cet outil, pensé pour des imports ponctuels de quelques centaines à quelques milliers de lignes depuis l'interface d'administration, n'était pas dimensionné pour ce volume. Passé les dix mille premières lignes, les temps de traitement devenaient incompatibles avec la fenêtre de bascule.

## Pourquoi l'import natif a atteint ses limites

L'import CSV standard traite chaque ligne comme une opération complète : création ou mise à jour du produit via les classes CRUD de WooCommerce, régénération des caches associés, déclenchement des hooks habituels comme `woocommerce_new_product`. Cette approche, parfaitement adaptée à un usage courant, cumule un coût non négligeable par ligne dès que le volume dépasse quelques milliers d'entrées, en particulier pour les produits variables où chaque variation déclenche son propre traitement.

Sur l'environnement de test, un import de 5 000 lignes prenait déjà plus de quarante minutes, avec des signes clairs de ralentissement progressif, cohérents avec une accumulation de données en cache non purgées entre deux lots.

## Le script par lots en ligne de commande

> L'essentiel à retenir : L'import CSV natif n'a pas tenu au-delà de quelques milliers de lignes ; WP-CLI et un script par lots ont sauvé le calendrier ; Désactiver la synchronisation Analytics pendant l'import était indispensable

La solution retenue s'est appuyée sur WP-CLI plutôt que sur l'interface d'administration, avec un script PHP personnalisé exécuté par lots de 500 références, chaque lot étant lancé comme une commande WP-CLI distincte pour repartir sur un processus PHP neuf à chaque fois :

```
wp eval-file import-lot.php --lot=1 --taille=500
wp eval-file import-lot.php --lot=2 --taille=500
# ... jusqu'au dernier lot, orchestré par un script bash
```

Ce découpage en processus séparés a réglé un problème récurrent en environnement de test : la mémoire PHP consommée par le cache d'objets WordPress qui grossit au fil de l'import et finit par atteindre la limite fixée par `memory_limit`, même avec un import censé traiter les lignes une par une. Relancer un processus neuf à chaque lot repart avec une mémoire propre.

## Ce qui a fait la différence pendant l'import

Trois ajustements ont eu un effet mesurable sur la durée totale de l'opération :

- La désactivation temporaire de la synchronisation WooCommerce Analytics vers ses tables de lookup, dont les tâches Action Scheduler saturaient la file d'attente pendant l'import massif.
- L'ajout de `wp_suspend_cache_addition( true )` en début de script, pour éviter que chaque écriture n'alimente inutilement le cache d'objets pendant une opération en ligne de commande qui ne bénéficie de toute façon pas de ce cache par la suite.
- La désactivation des révisions de contenu pour la durée de l'import, via la constante `WP_POST_REVISIONS` mise à zéro, WooCommerce créant une entrée de type article pour chaque produit.

Sans ces trois ajustements réunis, la première estimation de durée totale approchait les dix-huit heures. Après optimisation, l'import complet des 40 000 références, variations comprises, s'est terminé en un peu moins de six heures, une marge suffisante pour tenir la fenêtre du week-end annoncée au client.

## Ce qui a quand même posé problème

Deux incidents ont marqué cette bascule, malgré la préparation. D'abord, un sous-ensemble d'environ 300 références comportait des caractères d'encodage invalides dans le fichier source, provoquant l'arrêt silencieux du script sur le lot concerné faute de gestion d'exception explicite autour de la lecture CSV. La correction, un simple `try/catch` autour du traitement de chaque ligne avec journalisation de l'erreur plutôt qu'un arrêt du lot entier, aurait dû être prévue dès la première version du script.

Ensuite, la réindexation du moteur de recherche interne du site, non désactivée pendant l'import par oubli, a doublé la charge serveur pendant plusieurs heures sans que personne ne s'en aperçoive avant la revue du lendemain matin, retardant légèrement la vérification finale du catalogue.

> Sur un import de cette taille, la question à se poser en premier n'est jamais « combien de temps ça va prendre », mais « qu'est-ce qui, à chaque ligne traitée, se déclenche sans qu'on l'ait décidé explicitement ».

## Retour d'expérience pour la prochaine migration

Ce projet a confirmé que l'outil d'import natif de WooCommerce, très correct pour un usage courant, ne doit jamais être le point de départ d'un chiffrage sur un catalogue dépassant quelques milliers de références. Un script par lots en ligne de commande, avec une désactivation ciblée des mécanismes annexes qui alourdissent chaque écriture, change radicalement l'ordre de grandeur du temps nécessaire. La prochaine fois, le script inclura dès la première version une gestion d'erreur ligne par ligne et une checklist explicite des services annexes à désactiver, plutôt que de les découvrir un par un pendant l'exécution.