# Mes tâches automatiques ne s’exécutent plus

> Une tâche planifiée n’a personne pour lire son message d’erreur. Elle s’exécute la nuit, sans navigateur, sans utilisateur, et quand elle échoue, rien ne le signale. Le problème se découvre plusieurs jours plus tard, par un flux périmé ou un stock faux. C’est la panne la plus discrète et la plus coûteuse de cette rubrique.

- Source canonique : [https://allaux.fr/problemes/taches-automatiques-arretees](https://allaux.fr/problemes/taches-automatiques-arretees)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Appelez l’URL de la tâche à la main dans le navigateur, jeton compris : si elle s’exécute, le problème est le déclencheur et non le script. Sur WordPress, WP-Cron ne part qu’avec les visites, sauf si DISABLE_WP_CRON est à true dans wp-config.php et qu’une tâche serveur appelle wp-cron.php. Sur PrestaShop, l’URL du module de tâches planifiées contient un jeton qui change avec la clé de la boutique.

## Deux façons très différentes de planifier

Il existe deux mécanismes, souvent confondus. Le premier est une tâche planifiée au niveau du serveur : le système déclenche une commande à heure fixe, indépendamment du trafic. C’est fiable, mais cela demande un accès à l’hébergement pour la créer et la vérifier.

Le second est un déclenchement au passage d’un visiteur : le CMS vérifie à chaque page si une tâche est due, et l’exécute si c’est le cas. C’est simple à mettre en place, mais cela signifie qu’une boutique sans visiteurs n’exécute rien, et qu’une tâche longue est interrompue en même temps que la page qui l’a déclenchée. Une bonne part des « tâches qui ne s’exécutent plus » sont en réalité des tâches de ce second type sur un site à faible trafic nocturne.

## Vérifier si elle s’exécute vraiment

1. **Chercher la trace de la dernière exécution** — Date du fichier généré, dernière ligne du journal, horodatage en base. Sans trace, on ne sait pas si la tâche échoue ou si elle n’est jamais déclenchée : ce sont deux problèmes distincts.
2. **Lancer la commande à la main** — Si elle fonctionne manuellement mais pas en automatique, le problème est dans la planification, pas dans le traitement. C’est le test qui divise le champ des causes en deux.
3. **Vérifier le contexte d’exécution** — Une tâche lancée par le serveur n’a ni session ni utilisateur connecté, et parfois une version de PHP différente de celle du site. Un traitement qui suppose un utilisateur échoue silencieusement.
4. **Contrôler la durée** — Si la tâche met plus longtemps que l’intervalle qui la sépare de la suivante, deux exécutions se chevauchent. Selon le traitement, cela produit des doublons ou un blocage en base.
5. **Vérifier les jetons d’accès** — Beaucoup de tâches sont déclenchées par une adresse protégée par une clé. Une clé régénérée lors d’une réinstallation invalide toutes les planifications existantes, sans aucun message.

## Une tâche qui échoue doit vous le dire

> Le vrai correctif n’est pas de relancer la tâche : c’est de faire en sorte qu’un échec produise une alerte. Un simple courriel envoyé en cas d’erreur, ou un fichier d’état daté que l’on peut consulter, transforme une panne invisible en incident détecté le jour même.

## Ce qui casse une planification sans prévenir

Un changement d’hébergeur : les tâches serveur ne sont pas copiées avec les fichiers et doivent être recréées.

Un changement de version de PHP : la commande planifiée peut appeler un exécutable qui n’existe plus sous le même nom.

Un déplacement du site dans un autre répertoire : le chemin absolu inscrit dans la tâche ne mène plus nulle part.

Un module désinstallé qui emporte ses propres tâches, ou en laisse d’orphelines qui échouent à chaque tentative.

Un mot de passe ou une clé d’accès à un service externe arrivé à expiration.

## Continuer sur la bonne page

- **Tâches cron sur PrestaShop** — Le détail du fonctionnement et des pièges propres à PrestaShop. ([/prestashop/problemes/taches-cron-ne-sexecutent-pas](/prestashop/problemes/taches-cron-ne-sexecutent-pas))
- **Le cron expliqué** — Ce qu’est une tâche planifiée et comment elle est déclenchée. ([/glossaire/cron](/glossaire/cron))
- **Automatisation** — Quand l’enchaînement de traitements mérite d’être repensé plutôt que réparé. ([/services/automatisation](/services/automatisation))
- **Connecter un flux de produits** — Si la tâche en panne alimente un comparateur ou une marketplace. ([/guides/connecter-flux-produits](/guides/connecter-flux-produits))

## FAQ

### Comment savoir depuis quand la tâche ne tourne plus ?

La date de modification du fichier qu’elle produit donne la réponse immédiatement. Si elle n’écrit rien, la dernière donnée à jour en base donne l’ordre de grandeur.

### Puis-je remplacer une tâche serveur par un service externe qui appelle une adresse ?

Oui, c’est une solution courante quand l’hébergement ne permet pas de créer de tâches. L’adresse doit alors être protégée par une clé, sinon n’importe qui peut déclencher le traitement.

### Deux exécutions en même temps, est-ce grave ?

Cela dépend du traitement. Sur un import ou une synchronisation, oui : les données sont écrites deux fois ou entrent en conflit. Un verrou empêchant le chevauchement est la parade habituelle.

### La tâche s’exécute mais ne fait rien, pourquoi ?

Souvent parce qu’une condition en tête de traitement n’est plus remplie : un module désactivé, un réglage vidé, une source de données injoignable. Le journal du traitement lui-même est alors indispensable.

### Faut-il des tâches automatiques sur une petite boutique ?

Cela dépend de ce qu’elles font. Vider un cache ou nettoyer des paniers abandonnés est utile à toute taille ; synchroniser un catalogue avec un logiciel de gestion n’a de sens que si ce logiciel existe.