Cron PrestaShop qui ne fonctionne pas : la panne invisible

La panne dont personne ne s'aperçoit

Un cron PrestaShop qui ne fonctionne pas ne provoque aucune erreur visible. La boutique tourne, les commandes arrivent. Mais le flux produit envoyé aux comparateurs date de trois semaines, les stocks ne se synchronisent plus avec l'ERP, les relances de panier abandonné ne partent pas, et l'export comptable du mois est vide.

Le marchand découvre le problème par un tiers : un client qui commande un produit épuisé, ou un comptable qui réclame un fichier. Entre-temps, plusieurs semaines de dégâts se sont accumulées.

Le malentendu de départ

Le module ps_cronjobs est un ordonnanceur interne, pas un déclencheur. Il tient la liste des tâches et sait laquelle doit s'exécuter, mais il ne se réveille pas tout seul : il faut qu'une tâche planifiée réelle, configurée chez votre hébergeur, appelle son URL à intervalle régulier.

Beaucoup d'installations s'arrêtent là : les tâches sont créées dans le back-office, tout paraît correct, et rien ne s'exécutera jamais. Le module propose parfois de s'appuyer sur le trafic des visiteurs pour se déclencher, ce qui est imprévisible et inutilisable pour une tâche qui doit tourner à heure fixe.

Les cinq causes réelles

1. Aucune tâche planifiée côté hébergeur. Vérifiez dans le panneau d'administration de votre hébergement, section « tâches planifiées » ou « cron ». Si la liste est vide, vous avez trouvé.

2. La mauvaise version de PHP. C'est le piège des mutualisés. Les tâches planifiées s'exécutent en PHP en ligne de commande, dont la version est souvent différente de celle utilisée par le site. Le script tombe alors sur un PHP ancien et échoue immédiatement, sans que personne ne lise la sortie. Il faut indiquer le chemin absolu du bon interpréteur :

/usr/local/php8.2/bin/php /home/compte/site/modules/ps_cronjobs/cron.php

3. Un jeton invalide. L'URL des tâches contient un jeton de sécurité. Il change lors d'une réinstallation du module, ou d'un changement de configuration. Toutes les tâches enregistrées chez l'hébergeur renvoient alors une erreur d'autorisation, silencieusement.

4. Un appel bloqué. Une boutique protégée par une authentification HTTP, une règle de pare-feu applicatif, ou une restriction d'accès par adresse IP renvoie une erreur avant même d'atteindre PrestaShop.

5. Un dépassement du temps d'exécution. Une tâche lourde, comme la réindexation de la recherche ou un export catalogue volumineux, dépasse la limite autorisée et s'interrompt en plein milieu. Le pire cas : elle laisse des données partiellement traitées.

Le diagnostic en trois minutes

Test 1 : la tâche fonctionne-t-elle en HTTP ? Copiez l'URL complète de la tâche, jeton inclus, et ouvrez-la dans une fenêtre de navigation privée. Si elle s'exécute, le problème n'est pas dans PrestaShop mais dans le déclenchement externe.

Test 2 : la ligne de commande fonctionne-t-elle ? Exécutez-la en SSH avec le chemin absolu de l'interpréteur PHP. Un message d'erreur de syntaxe indique une version de PHP inadaptée.

Test 3 : que dit le journal ? Ajoutez systématiquement une redirection de sortie dans votre tâche planifiée :

wget -q -O - "https://boutique.fr/modules/ps_cronjobs/cron.php?token=XXXX" >> /home/compte/logs/cron.log 2>&1

Sans journal, vous diagnostiquez à l'aveugle. C'est la modification la plus rentable de tout cet article.

La configuration recommandée

Préférez l'appel HTTP à l'exécution en ligne de commande pour les tâches PrestaShop. Avec wget ou curl, le script s'exécute dans le même contexte que le site : même version de PHP, mêmes variables d'environnement, mêmes permissions. C'est la première source d'écarts éliminée.

Espacez les tâches. Trois exports catalogue déclenchés à la même minute saturent le serveur et se font mutuellement échouer. Décalez-les de quelques minutes.

Choisissez les heures creuses pour les traitements lourds, en tenant compte de vos horaires réels de vente.

Fixez une limite de temps à vos scripts lourds et découpez-les par lots. Un export de 50 000 références doit se traiter en tranches, avec un point de reprise.

Surveiller, sinon rien

Un cron muet reste une panne invisible, même bien configuré. La seule protection consiste à surveiller son exécution.

Le principe est simple : votre tâche appelle, à la fin de son exécution, une URL de contrôle fournie par un service de supervision. Si l'appel n'arrive pas dans la fenêtre attendue, vous recevez une alerte. Vous êtes prévenu de l'absence d'exécution, pas seulement de l'erreur — c'est exactement ce qui manque ici.

À défaut d'outil externe, un contrôle hebdomadaire suffit à limiter les dégâts : vérifier la date du dernier flux généré, la date du dernier export comptable, et la fraîcheur de la synchronisation de stock.

Sur le même sujet, les emails de relance qui ne partent pas relèvent souvent d'un cron muet plutôt que d'un problème d'envoi : voyez le diagnostic des emails PrestaShop.

Faire fiabiliser vos tâches planifiées

Nous auditons vos tâches, corrigeons leur déclenchement et mettons en place la surveillance. Voir notre offre de gestion de site e-commerce.