La boutique gère trois entrepôts physiques, chacun avec son propre système de gestion d’inventaire, et un script maison recalcule le stock consolidé de chaque référence WooCommerce. Le développeur d’origine, inquiet qu’un client commande un article en rupture, a réglé la fréquence de synchronisation sur une minute. Le raisonnement semblait raisonnable en apparence : plus la synchronisation est fréquente, plus le stock affiché est fiable. En pratique, cette décision a fini par ralentir toute la boutique, bien avant que le trafic ne justifie une telle charge.
Ce cas revient régulièrement chez les développeurs qui héritent d’un projet multi-entrepôts : la fréquence de synchronisation est traitée comme un simple paramètre de configuration, sans considération pour ce qu’elle déclenche réellement en base de données à chaque exécution.
Ce qu’on voit
Le tableau de bord d’hébergement montrait des pics de charge processeur réguliers, espacés de soixante secondes, visibles même en dehors des heures de trafic. Le journal de requêtes lentes MySQL affichait, à chaque pic, des dizaines de requêtes UPDATE sur la table wp_postmeta, correspondant à la mise à jour de la métadonnée _stock de plusieurs centaines de produits, à chaque exécution du script.
Le symptôme le plus visible pour l’utilisateur final restait toutefois plus insidieux : des ralentissements intermittents de quelques secondes sur les pages produit et sur le panier, sans lien apparent avec le nombre de visiteurs simultanés.
Pourquoi c’est un problème
Deux mécanismes s’ajoutent l’un à l’autre pour expliquer cette dégradation. D’abord, wp-cron n’est pas un vrai service de planification système : par défaut, il se déclenche à chaque chargement de page front-end, WordPress vérifiant à ce moment-là si une tâche planifiée est due. Sur une boutique avec un trafic soutenu, cela signifie que la tâche de synchronisation peut se déclencher bien plus souvent que prévu, parfois en parallèle sur plusieurs requêtes simultanées si aucun verrou applicatif ne l’empêche.
Ensuite, chaque appel à wc_update_product_stock() ou à $product->save() ne se contente pas d’écrire une valeur en base : il déclenche la série de hooks associés, dont woocommerce_product_set_stock, invalide les caches de disponibilité, et sur certaines configurations régénère des transients de prix ou de variation. Multiplié par plusieurs centaines de produits, soixante fois par heure, la charge cumulée dépasse largement ce que suggérerait le volume de données réellement modifiées.
Le coût caché des verrous
Sur une table InnoDB comme wp_postmeta, des écritures concurrentes sur des lignes proches peuvent provoquer des attentes de verrou, en particulier lorsque la tâche de synchronisation se chevauche avec elle-même parce que l’exécution précédente n’est pas terminée avant que la suivante ne démarre. C’est exactement ce qui se produisait ici : le script mettait en moyenne quarante secondes à s’exécuter, pour une fréquence programmée à soixante secondes, laissant une marge insuffisante dès que l’un des trois entrepôts répondait plus lentement que d’habitude.
Que faire à la place
La première mesure a été de désactiver wp-cron déclenché par le trafic, via la constante DISABLE_WP_CRON dans wp-config.php, au profit d’un vrai cron système appelant wp-cron.php à intervalle maîtrisé :
define( 'DISABLE_WP_CRON', true );
# crontab système, exécution toutes les quinze minutes
*/15 * * * * curl -s https://exemple.fr/wp-cron.php?doing_wp_cron > /dev/null 2>&1
Ensuite, la fréquence de synchronisation elle-même a été revue à la baisse, avec une différenciation par criticité :
- Toutes les quinze minutes pour l’ensemble du catalogue, un délai largement suffisant pour un site qui n’a pas de vente flash permanente.
- En temps quasi réel, via un webhook déclenché par le système d’entrepôt lui-même, pour les seules références passées en rupture, afin d’éviter la survente sur les articles à faible stock.
- Un verrou applicatif simple, basé sur un transient, empêchant deux exécutions du script de se chevaucher si l’une d’elles dépasse la durée prévue.
La fréquence idéale d’une synchronisation n’est jamais « le plus souvent possible » : c’est le point où le risque de stock obsolète devient réellement plus coûteux que le coût de la synchronisation elle-même.
En résumé
Une synchronisation par minute donne l’illusion de la précision, mais elle transforme un besoin métier raisonnable en une charge technique disproportionnée, avec des effets de bord difficiles à relier à leur cause pour qui découvre le projet après coup. La bonne fréquence dépend du volume de produits, du trafic réel de la boutique et de la criticité de chaque référence, pas d’une intuition de prudence appliquée uniformément à tout le catalogue.
