Reconnaître le problème que vous cherchez à résoudre
Une sauvegarde automatique ne démarre plus, des actions restent en attente dans WooCommerce ou l’hébergeur signale une consommation régulière de ressources. Dans Santé du site, WordPress peut aussi annoncer qu’un événement planifié est en retard. L’objectif est de retrouver un traitement régulier des tâches utiles, tout en préservant les commandes, les fichiers et les opérations déjà effectuées.
Ce guide concerne les tâches de fond. Il ne constitue pas une méthode générale pour accélérer toutes les pages. Une administration lente, sans événement retardé ni processus identifié, demande un autre diagnostic. De même, quelques actions futures dans une liste ne démontrent pas une panne : elles peuvent simplement attendre leur heure.
Commencez avec l’administration et les outils de l’hébergeur. Le terminal est une troisième approche, réservée à la personne qui dispose déjà de cet accès. Vous n’avez pas besoin d’installer une extension de nettoyage pour mener les premières observations. Aucun essai sur un site réel n’est revendiqué dans ce guide.
Distinguer WP-Cron, le planificateur serveur et Action Scheduler
WP-Cron est le mécanisme de planification de WordPress. Il garde les événements à exécuter, comme certaines vérifications de mises à jour ou publications programmées. Dans son fonctionnement habituel, des requêtes arrivant à WordPress donnent l’occasion de démarrer les événements échus. Ce n’est pas un service qui tourne en permanence à chaque seconde.
Un site peu visité peut donc accumuler du retard. Le trafic mesuré ne suffit cependant pas à conclure : une page servie entièrement par un cache peut ne pas faire travailler WordPress. À l’inverse, recevoir des visites ne garantit pas qu’un appel interne ou une fonction d’extension réussit.
Le planificateur serveur appartient à l’hébergement. Il peut déclencher WordPress à intervalles réguliers, indépendamment des visites. Une ligne enregistrée dans ce planificateur ne prouve pas que la bonne installation est appelée ni que le travail aboutit.
Action Scheduler est une bibliothèque utilisée par des extensions, notamment WooCommerce. Elle possède sa propre file d’actions et ses journaux. Son traitement habituel s’appuie notamment sur WP-Cron et des appels internes asynchrones. L’événement action_scheduler_run_queue lance le traitement de cette file ; il ne représente pas chaque commande ou chaque courriel qu’elle contient.
Préserver les données et comprendre les effets possibles
Une tâche de fond peut envoyer un message, transmettre une commande, modifier un abonnement ou appeler un prestataire de paiement. Ne cliquez pas sur Exécuter pour découvrir ce qu’elle fait. Une action marquée en échec peut avoir produit une partie de ses effets avant de s’arrêter. La relancer peut donc répéter une opération déjà accomplie.
Avant une modification, faites conserver une sauvegarde récente de la base et des fichiers, ainsi que les journaux utiles. Stockez ces éléments dans un espace privé, pas dans le répertoire public du site. Notez la configuration actuelle du planificateur et l’heure de votre intervention. Sur une boutique active, les nouvelles commandes continuent à rendre les données plus récentes que la sauvegarde.
Ne restaurez pas toute la base pour annuler un réglage Cron : vous pourriez perdre ces commandes, des comptes ou des changements de stock. Le retour arrière doit d’abord viser le réglage précis modifié. Toute restauration de données commerciales demande un rapprochement séparé avec les opérations intervenues depuis.
Pour une reproduction sur copie, faites neutraliser les paiements, courriels, SMS, synchronisations et tâches externes dès la création de cette copie, avant sa première visite. Un environnement nommé préproduction peut encore contenir les clés et files de production. Une simple duplication n’assure pas son isolement.
Construire un relevé court avant toute correction
Notez le premier symptôme, son heure avec le fuseau, et le dernier fonctionnement connu. Relevez les changements proches : migration, mise à jour, ajout d’un pare-feu, changement de domaine, import important ou modification d’une sauvegarde. Un rapprochement temporel donne une piste ; il ne prouve pas à lui seul la responsabilité du dernier composant modifié.
Pour chaque tâche représentative, gardez son nom technique, sa date prévue, son statut et, si disponible, son identifiant. Le nom technique est souvent appelé hook : c’est le nom auquel WordPress rattache le travail à effectuer. Dans Action Scheduler, ajoutez le groupe et quelques lignes pertinentes du journal.
Comparez les dates dans le même fuseau. Une heure indiquée en UTC ne doit pas être directement comparée à une heure locale sans conversion. Dans WordPress, Réglages, Général permet de consulter le fuseau du site ; ne le changez pas simplement pour faire disparaître un retard apparent.
Limitez les informations transmises au support. Les arguments d’une tâche peuvent contenir des identifiants de commandes, des adresses ou d’autres données privées. Gardez le relevé complet dans un emplacement protégé et masquez ces valeurs dans un forum public.
Choisir la piste selon ce qui progresse encore
Observez la situation à deux moments séparés par plusieurs intervalles attendus, sans rafraîchir continuellement l’administration. Un compteur isolé décrit mal une file qui reçoit de nouvelles actions pendant qu’elle en termine d’autres. Suivez aussi l’âge de la plus ancienne action échue et les erreurs récentes.
- Plusieurs familles de tâches restent en retard : vérifiez d’abord leur déclenchement et les appels internes.
- Un seul nom échoue tandis que les autres progressent : examinez son extension, ses arguments et l’erreur associée.
- Des actions se terminent, mais les entrées arrivent plus vite : cherchez le travail qui alimente la file et les limites du traitement.
- Seules des actions futures ou d’anciens échecs sont visibles : établissez leur effet réel avant de parler de blocage actuel.
Approche 1 : commencer dans l’administration WordPress
Avec votre accès autorisé, ouvrez Outils, Santé du site, puis l’onglet État. Relevez les messages concernant les événements planifiés et les requêtes de bouclage, également appelées loopbacks. L’onglet Informations aide à identifier l’environnement et les versions ; il ne remplace pas les journaux d’exécution du serveur.
Une requête de bouclage permet au serveur de demander une adresse de son propre site. Le contrôle intégré de Santé du site emploie une requête particulière conçue pour terminer sans exécuter les tâches Cron. Son succès ne prouve donc pas qu’un événement métier s’est achevé. Il vérifie un trajet technique, avec des limites différentes de celles d’une exécution complète.
Consulter l’administration n’immobilise pas les mécanismes normaux du site : certaines requêtes administratives peuvent contribuer au démarrage du traitement habituel. N’utilisez pas des rechargements répétés comme méthode de rattrapage. Si un traitement réel paraît dangereux ou dupliqué, faites d’abord organiser sa suspension ciblée par le responsable technique.
WordPress ne fournit pas dans cet écran la liste détaillée de toutes les tâches de chaque extension. Cherchez ensuite le journal propre au composant concerné, par exemple son historique de sauvegardes ou d’imports.
Lire la file Action Scheduler sans la modifier
Lorsque la bibliothèque est présente et que votre compte y a accès, cherchez Outils, Actions planifiées, ou WooCommerce, État, Actions planifiées. Selon la langue, l’interface affiche Scheduled Actions. L’absence du menu ne signifie pas que toute planification est arrêtée : le site peut utiliser un autre mécanisme ou votre compte ne pas avoir les droits nécessaires.
Filtrez les actions en attente, puis examinez leur date. Le statut Pending inclut des actions prévues pour l’avenir ; concentrez-vous sur celles dont l’échéance est dépassée. Consultez séparément Failed, In-progress et Complete, soit les échecs, les actions en cours et celles terminées. Ouvrez le détail ou le journal d’un petit nombre d’actions représentatives.
Relevez le hook, le groupe, l’identifiant et la succession des messages. Une création sans démarrage oriente vers le lancement ou la disponibilité du traitement. Un démarrage suivi d’une erreur oriente vers le travail exécuté. Ces indices ne donnent pas automatiquement la cause exacte, mais ils permettent de poser une question précise au bon support.
N’utilisez ni les actions groupées de suppression ni le bouton de lancement manuel. Une liste plus courte après suppression ne démontre aucune réparation. Les journaux et identifiants sont justement utiles pour comprendre ce qui reste à faire.
Interpréter les échecs et les opérations partielles
Un statut en cours prolongé peut correspondre à un travail lent, interrompu ou encore actif. Action Scheduler gère des limites et des réservations de lots ; n’effacez pas ses verrous ou ses tables pour forcer le passage. Son fonctionnement documenté permet aussi qu’une action considérée en échec après un délai soit ensuite marquée terminée si son travail aboutit.
Pour une action liée à une commande, rapprochez le journal de la file, les notes de commande et l’état chez le prestataire concerné. Un courriel peut avoir été envoyé avant une erreur ultérieure. Un service distant peut avoir accepté une opération sans que WordPress ait enregistré sa réponse. Seul le statut de la file ne permet pas de garantir l’absence d’effet.
Demandez à l’éditeur de préciser si la reprise détecte une opération déjà réalisée et comment elle évite de la refaire. Pour des paiements ou renouvellements, faites traiter le cas par la personne responsable de la boutique. Ne créez pas une transaction réelle de test et ne changez pas artificiellement une action en réussite pour retirer l’alerte.
Examiner les blocages de bouclage avec l’hébergeur
Un refus 401 ou 403, une erreur TLS ou un délai dépassé donne une direction différente. Transmettez le message exact, l’heure et l’adresse concernée par un canal privé. Demandez à l’hébergeur de rapprocher ces éléments de ses journaux et de vérifier que le serveur peut joindre le domaine attendu.
Les protections HTTP, règles de pare-feu, DNS et certificats peuvent intervenir. Faites corriger la règle ou la destination démontrée comme responsable. Désactiver globalement la sécurité, enlever toutes les protections ou désactiver la vérification des certificats n’est pas une correction appropriée. Une copie protégée par mot de passe peut, elle aussi, modifier le comportement des appels internes.
Après la correction ciblée, consultez de nouveau le contrôle natif et les journaux. Si les appels fonctionnent mais que les actions échouent toujours, poursuivez sur la fonction exécutée. Si aucune requête n’atteint le serveur attendu, faites vérifier le trajet avant d’ajouter un nouveau planificateur.
Approche 2 : vérifier le planificateur de l’hébergement
Cette approche convient aux sites peu visités, aux migrations et aux installations où WP-Cron a été désactivé. Dans le panneau d’hébergement, consultez la rubrique des tâches planifiées ou demandez son état au support. Ne créez pas une deuxième tâche avant d’avoir identifié les tâches existantes, y compris celles gérées par un service externe.
Faites relever le domaine ou le chemin appelé, la fréquence, le compte d’exécution et les dernières sorties disponibles. Le chemin doit correspondre à l’installation actuelle, pas à l’ancien site ou à la préproduction. Si le traitement utilise PHP en ligne de commande, son environnement peut différer de celui du serveur web ; l’hébergeur doit vérifier le binaire et les droits nécessaires.
Demandez aussi si une ancienne exécution tourne encore quand la suivante commence. Augmenter la fréquence sans connaître la durée du travail peut multiplier les processus. La fréquence doit être adaptée aux besoins du site et aux ressources disponibles, pas copiée d’un exemple universel.
Une trace de lancement du planificateur ne suffit pas. Il faut également une sortie cohérente, l’absence d’erreur récente et une progression du travail prévu. Même une réponse HTTP normale ne garantit pas que tous les callbacks WordPress ont terminé.
Corriger une désactivation de WP-Cron sans créer un second problème
La constante DISABLE_WP_CRON définie à true dans la configuration empêche le déclenchement automatique habituel lié aux requêtes WordPress. Elle n’efface pas les événements et ne prouve pas qu’un remplacement fonctionne. Sur une offre administrée, cette valeur peut être volontaire et accompagnée d’un mécanisme du prestataire.
Cette constante peut être définie dans wp-config.php ou par une configuration fournie par l’hébergeur. Consultez seulement sa valeur avec la personne autorisée, sans copier le fichier complet dans un ticket. Faites confirmer sa raison d’être avant de la modifier. Si aucun remplacement n’existe, deux corrections sont possibles avec le responsable du site : rétablir le déclenchement habituel, ou mettre en place un planificateur serveur adapté. Dans les deux cas, identifiez d’abord les actions en retard et leurs effets possibles ; la reprise peut rendre des opérations anciennes immédiatement exécutables.
Pour passer au planificateur serveur, faites préparer puis valider son fonctionnement avant de désactiver le déclenchement habituel. Organisez la transition avec l’hébergeur afin d’éviter les appels concurrents inutiles. La validation préalable peut utiliser un contrôle technique isolé sans paiement ni message réel ; elle ne consiste pas à lancer toute la file de production.
Si le nouveau mécanisme échoue, rétablissez la configuration documentée avec le responsable et supprimez seulement le déclencheur nouvellement ajouté si nécessaire. Ne laissez pas le site sans mécanisme actif. Ne restaurez ni base ni fichiers anciens pour revenir sur cette seule modification.
Approche 3 : inventorier WP-Cron avec un accès technique
Si WP-CLI est déjà disponible, la personne autorisée peut l’utiliser depuis le répertoire de la bonne installation. Confirmez d’abord le site et le compte utilisés avec l’hébergeur. Les commandes ci-dessous consultent la configuration ou la liste ; elles ne demandent pas l’exécution des événements. Le chargement des extensions reste celui de l’environnement concerné.
La première lit uniquement la constante ciblée, sans afficher toute la configuration ni ses secrets. La seconde présente les noms, les prochaines dates en GMT, les délais relatifs et les récurrences. Conservez les résultats dans un espace privé si vous les exportez.
Si la constante n’est pas trouvée, ne concluez pas qu’aucun blocage n’existe : des filtres, une configuration particulière ou l’infrastructure peuvent intervenir. Si WordPress ne se charge pas, relevez l’erreur et arrêtez cette approche. Ne désactivez pas les extensions uniquement pour obtenir une liste artificiellement différente du fonctionnement réel.
wp config get DISABLE_WP_CRON --type=constant
wp cron event list --fields=hook,next_run_gmt,next_run_relative,recurrence --format=tableLire ces résultats sans transformer l’inventaire en relance
La liste WP-Cron n’est pas le contenu détaillé de la file Action Scheduler. Voir son événement de lancement ne permet pas de connaître le nombre d’actions métier échouées. Revenez à l’écran de la file pour ces détails. Les commandes propres à Action Scheduler dépendent aussi de sa version ; le technicien doit consulter leur aide avant toute utilisation.
N’exécutez pas de commande destinée à lancer tous les événements échus, à vider une file ou à forcer la concurrence. Même wp cron test, malgré son nom, tente de démarrer WP-Cron par HTTP : ce n’est pas une simple consultation. Ne l’utilisez pas pour cette phase de relevé sur une boutique réelle.
Si vous n’avez ni terminal ni journal détaillé, demandez l’inventaire à l’hébergeur. Un outil comme WP Crontrol peut aussi afficher les événements lorsque son installation est autorisée. Ce recours est facultatif, après les outils existants. Restez sur la consultation ; ses fonctions de création, pause, exécution et suppression ne sont pas nécessaires pour lire une liste.
Réparer la fonction qui échoue ou la création excessive de tâches
Lorsqu’un seul hook accumule les erreurs, identifiez son propriétaire avec les journaux, la documentation et le support de l’extension. Le préfixe du nom est un indice, pas une preuve. Une fonction associée, souvent appelée callback, peut manquer, ne pas se charger dans ce contexte ou s’arrêter sur une erreur PHP.
Transmettez l’erreur complète après retrait des données privées, la version du composant et un identifiant représentatif. Une mise à jour corrective doit être préparée sur une copie isolée et appliquée avec un retour arrière compatible avec les données actuelles. Réactiver une ancienne extension uniquement pour « retrouver le hook » peut réintroduire d’autres effets.
Plusieurs événements de même nom ne sont pas forcément des doublons : leurs dates ou arguments peuvent correspondre à des opérations différentes. Si le code recrée inutilement une tâche, il faut corriger cette création avant d’envisager un nettoyage ciblé avec l’éditeur. Ce guide ne propose pas de suppression par nom ni de modification directe de l’option Cron en base.
Réduire le volume à traiter plutôt que forcer la file
Quand les actions aboutissent mais que le retard augmente, cherchez ce qui produit le volume : import répété, synchronisation trop fréquente, reprise en boucle d’un service indisponible ou lancement simultané de travaux lourds. Comparez l’évolution de la file avec les métriques et journaux de l’hébergement sur la même période.
Faites ajuster, dans le composant concerné, la fréquence ou le lancement des travaux non urgents. Préservez les opérations commerciales et les sauvegardes nécessaires. Suspendre globalement une extension peut retirer les fonctions dont la file a besoin ; une suspension doit donc être ciblée, comprise et réversible.
Action Scheduler traite le travail avec des limites. Augmenter aveuglément la mémoire, la taille des lots ou le nombre de traitements simultanés peut aggraver la charge. Un traitement spécialisé par terminal peut convenir à une grosse file, mais son dimensionnement appartient au technicien. Séparer des groupes sans examiner leurs dépendances peut modifier l’ordre attendu entre opérations.
Adapter le diagnostic à WordPress.com et au multisite
Sur WordPress.com, WP-Cron reste un mécanisme documenté ; la plateforme décrit aussi des possibilités de planification serveur. Faites confirmer les accès et le mécanisme réellement disponibles pour votre site par son support. Ne transposez pas un chemin cPanel ou une modification de configuration à une offre qui ne vous donne pas cet accès.
Dans un réseau multisite, relevez le sous-site touché et faites intervenir le responsable du réseau. Le bon fonctionnement du site principal ne prouve pas que tous les sous-sites sont ciblés. Avec WP-CLI, le paramètre --url sert notamment à sélectionner le site du réseau ; son adresse doit être confirmée avant l’inventaire.
Ne lancez pas une boucle de traitement sur tout le réseau pour vérifier un sous-site. L’inventaire des sites réellement couverts par le planificateur constitue une vérification distincte, particulièrement après une migration ou l’ajout d’un nouveau site.
Vérifier la reprise sans rejouer les opérations sensibles
Après correction, choisissez une période d’observation adaptée aux intervalles attendus. Relevez de nouveau les mêmes indicateurs : âge de la plus ancienne tâche échue, nombre d’actions nouvellement terminées, erreurs récentes et consommation de ressources. La diminution durable du retard est plus parlante que la disparition ponctuelle d’un avertissement.
Les observations portent sur les traitements légitimes que le site devait accomplir, pas sur des courriels ou paiements réels créés pour tester. Pour les actions précédemment échouées, l’éditeur ou le responsable métier doit déterminer lesquelles nécessitent une reprise et lesquelles ont déjà produit leur effet. Ce rapprochement précède toute relance sélective.
Une file saine peut garder des actions futures et un historique d’échecs. Le résultat recherché n’est donc pas une base vide. Vérifiez également qu’un réglage temporaire n’a pas laissé une sauvegarde, une synchronisation ou une fonction indispensable désactivée. Conservez le relevé de configuration et les preuves utiles au suivi.
Si la charge repart immédiatement ou si les mêmes erreurs reviennent, interrompez les nouvelles tentatives de rattrapage et transmettez le dossier. Évitez de répéter des réglages identiques qui ne changent pas le diagnostic.
Transmettre un dossier exploitable si le blocage persiste
Indiquez au support le mécanisme identifié, les dates comparables et quelques actions représentatives. Précisez ce qui fonctionne encore : autres événements, appels internes ou actions d’un autre groupe. Joignez la configuration utile du planificateur sans ses secrets, les erreurs exactes et les modifications déjà tentées avec leur résultat.
Deux messages appellent des investigations différentes. Un refus de bouclage oriente vers le trajet de la requête. Une erreur could_not_set concerne l’enregistrement de la liste Cron ; elle ne prouve pas à elle seule un manque de processeur ou une corruption de base. Il faut rapprocher ce message des écritures et journaux au même moment, sans effacer la liste pour le faire disparaître.
Demandez une conclusion concrète : cause retenue, correction appliquée, travail restant à reprendre et méthode d’observation. Gardez séparés le rétablissement du déclenchement et le traitement des opérations anciennes. Cette distinction protège les données récentes tout en permettant de vérifier que le site traite de nouveau ses tâches utiles.
