15 000 références sous PrestaShop : fiabiliser les imports et les tâches planifiées

Un catalogue de quelques centaines de produits se gère à la main. À 15 000 références, avec des prix qui bougent chaque semaine et des stocks partagés avec des magasins physiques, il se gère par des imports et des synchronisations automatiques. Et c’est à ce moment qu’apparaissent des pannes que les petites boutiques ne connaissent pas : un import qui s’arrête au milieu sans message clair, des stocks qui ne correspondent plus au magasin, une tâche planifiée qui tourne encore quand la suivante démarre.

Pourquoi l’import du back-office cède

L’import CSV intégré de PrestaShop s’exécute dans une requête web. Il est donc soumis aux limites du serveur web et de PHP : durée maximale d’exécution, mémoire, délai de coupure du proxy ou du répartiteur de charge. Sur un fichier de plusieurs milliers de lignes, avec génération des déclinaisons, des images et réindexation de la recherche, ces limites sont vite atteintes. Le résultat est le pire possible : un import partiel, sans liste fiable de ce qui a été traité.

Le même défaut touche les synchronisations déclenchées par une URL appelée depuis un cron externe. Tant que la tâche reste courte, tout va bien. Dès que le volume augmente, elle dépasse le délai de la requête HTTP et meurt silencieusement.

Une architecture en lots

Les boutiques qui tiennent la charge partagent quelques principes simples :

• La ligne de commande plutôt que le navigateur. Un script lancé par le cron du serveur échappe aux délais du serveur web. Il peut tourner dix minutes sans risque d’être coupé.
• Des lots de taille fixe. Quelques centaines de lignes par lot : un échec n’invalide qu’un lot, qui peut être rejoué seul.
• Un verrou. Une synchronisation ne démarre pas tant que la précédente n’est pas terminée. Sans verrou, deux exécutions concurrentes écrivent les mêmes stocks et produisent des chiffres faux.
• Le différentiel. Seuls les produits modifiés depuis la dernière exécution sont traités. Une synchronisation complète reste possible, mais la nuit, et rarement.
• Un journal lisible. Pour chaque exécution : durée, lignes lues, créées, modifiées, en erreur, avec la raison. C’est ce journal que l’on consulte quand un client signale un prix faux.

Passer par l’API du cœur, pas par la base

Écrire directement dans les tables de PrestaShop est tentant : c’est rapide. Mais PrestaShop maintient des caches, des tables de recherche, des prix spécifiques et des stocks par déclinaison qu’une écriture SQL brute ignore. Un script robuste utilise les classes du cœur (Product, StockAvailable, Combination) pour chaque écriture métier, et réserve le SQL direct aux lectures massives. La documentation développeur de PrestaShop décrit ces objets et leurs points d’extension.

Le stock, sujet le plus sensible

Quand un produit se vend à la fois en ligne et en magasin, la question n’est pas technique mais métier : qui fait foi ? La règle la plus sûre fixe une seule source de vérité (la caisse ou l’ERP) et une réserve de sécurité sur les articles à faible stock, pour ne pas vendre en ligne la dernière pièce déjà partie au comptoir. La fréquence de synchronisation se choisit ensuite en fonction du rythme des ventes, pas de ce que le serveur peut encaisser.

Ce qu’il faut retenir

• L’import du back-office et les crons par URL cèdent sur les gros volumes : les délais du serveur web les coupent.
• Lots de taille fixe, ligne de commande, verrou et différentiel rendent la synchronisation fiable et rejouable.
• Pour le stock, une seule source de vérité et une réserve de sécurité.