WP Crontrol ou Advanced Cron Manager avant une migration ?

Inventorier les tâches avant que deux copies puissent les lancer

Un site doit déménager d’un hébergement à l’autre. Les fichiers et la base sont prêts, mais certains traitements doivent continuer une seule fois. Une sauvegarde, une synchronisation ou une publication programmée peut se lancer après le déplacement. Si l’ancien et le nouveau site restent actifs ensemble, chacun peut voir une tâche due dans la copie de sa base. L’équipe doit savoir quel site la prend en charge et pouvoir vérifier ce qui a effectivement tourné.

WP Crontrol fournit un inventaire exportable et, depuis la version 2.0.0, des journaux gratuits pour les événements choisis. Advanced Cron Manager propose également la lecture et la gestion des événements ; ses outils de journal, de mesures et de débogage sont annoncés dans Pro. Le choix ne se réduit donc plus à « gratuit pour voir, payant pour observer ». Commencez par le relevé nécessaire à la migration, puis vérifiez les informations que chaque journal permet de rapprocher du résultat attendu.

Avant d’installer un outil, relevez la méthode actuelle de lancement des tâches. WordPress peut lancer WP-Cron lors des visites. Un hébergeur peut aussi appeler ce mécanisme depuis un planificateur externe. Si vous avez déjà une liste des tâches et les journaux d’un environnement maîtrisé, cette information peut suffire. L’extension devient utile lorsqu’il est difficile de rapprocher ce qui est planifié dans WordPress et ce que l’hébergement lance.

Le projet retenu porte sur la comparaison avant et après un transfert. Il est différent d’une réparation générale des tâches en retard. Une échéance ancienne peut attirer l’attention, mais ne justifie pas de lancer immédiatement la tâche. Le premier résultat attendu est une liste compréhensible des traitements et de leurs propriétaires, suivie d’une bascule qui laisse un seul site actif pour chacun.

• Lister les traitements qui ont un effet hors du site.
• Identifier comment WP-Cron est lancé aujourd’hui.
• Décider quelle preuve chaque traitement doit laisser.

Construire un relevé que l’équipe pourra comparer

Préparez un tableau avec le nom de la tâche, les arguments nécessaires à son identification, la fréquence, la prochaine échéance et le composant qui la déclare. Ajoutez un champ qui indique ce que la tâche fait. Une tâche de nettoyage local et un envoi à des clients n’ont pas le même effet. Si vous ne savez pas à quel plugin elle appartient, cherchez son nom dans la documentation ou demandez au responsable du site. Gardez l’événement dans le relevé pendant cette enquête.

Le nom technique d’un événement correspond à un crochet WordPress, souvent appelé hook. Deux lignes qui partagent ce nom peuvent viser des éléments différents si leurs arguments ne sont pas identiques. Une ligne qui semble en double peut par exemple traiter deux listes ou deux opérations distinctes. Comparez le nom et les arguments avec l’extension qui les utilise. Ne regroupez pas les lignes seulement parce que leur libellé est le même.

Notez le fuseau et la date du relevé. Une tâche récurrente attendue demain avant la copie peut apparaître le jour suivant sur le nouveau site si elle s’est exécutée entre les deux relevés. Une comparaison utile distingue une différence normale d’échéance, une disparition de tâche et une création en double. Pour une action ponctuelle, gardez aussi l’identifiant ou la référence du traitement si l’application en fournit un.

Les arguments peuvent contenir des identifiants de dossiers ou d’autres données internes. Conservez l’export dans un espace réservé à l’équipe et n’envoyez pas un CSV brut à une personne qui n’en a besoin que pour comprendre une seule tâche. Un résumé avec le nom, la fréquence et une référence tronquée suffit souvent. La première feuille de migration doit indiquer à qui signaler une ligne inconnue.

• Relever le nom, les arguments et l’échéance de chaque tâche importante.
• Classer les effets locaux et les effets externes.
• Consigner le fuseau et la personne responsable de la tâche.

Capturer les événements avec WP Crontrol

Sur une copie autorisée, ouvrez Cron → Cron Events dans WP Crontrol 2.0.0 ; Outils → Cron Events reste accessible selon la fiche officielle. Repérez les événements, leurs arguments et les actions associées. Recherchez d’abord les processus qui publient, envoient ou modifient un service externe. Pendant l’inventaire, laissez de côté les commandes de lancement, de pause et de suppression. Le but immédiat est de conserver un état lisible, avec le site et l’heure du relevé.

Utilisez le bouton Export pour conserver la liste en CSV. Ouvrez le fichier dans votre outil de lecture et relevez deux tâches connues. Vérifiez que les arguments et les échéances vous permettent de les retrouver. Le CSV sert à l’inventaire et au rapprochement. Gardez la sauvegarde de la base à part pour les réglages et les états. Un fichier de relevé ne doit pas être utilisé comme procédure d’import des événements sur le site cible.

Lorsque l’écran signale qu’aucune action n’est associée à une tâche, notez la ligne et le contexte. Sur une copie où certains plugins sont désactivés volontairement, ce signal peut être attendu. Comparez ensuite le même événement après activation de l’extension qui en est responsable dans un environnement correctement isolé. Une action absente après migration indique un point à expliquer. Elle ne suffit pas à décider de supprimer tous les événements portant le même nom.

Après le transfert, ouvrez le même écran sur la cible et exportez un second CSV. Comparez les lignes et notez quelles différences correspondent aux actions réalisées entre-temps. Si le planificateur de la cible reste suspendu pendant cette vérification, comparez le relevé sans lancer de tâche. Vous pouvez ensuite observer une tâche de test connue lorsque l’équipe a validé la prise en charge du site cible.

WP Crontrol 2.0.0 rend les journaux gratuits, mais ils restent inactifs tant que vous ne les activez pas pour un événement. Consultez ensuite Cron → Cron Logs pour le traitement choisi. Le changelog annonce une conservation de 30 jours et un plafond de 10 000 entrées par site ; supprimer le plugin supprime ses tables de journal et ses réglages. Récupérez donc les traces utiles avant une désinstallation. L’existence d’un menu de journal ne prouve pas qu’une exécution antérieure y a été enregistrée.

• Ouvrir Outils → Cron Events et exporter la liste.
• Comparer les tâches par nom et arguments.
• Faire un second relevé avant d’autoriser les traitements de la cible.

Préparer une observation ciblée dans Advanced Cron Manager

Sur une autre copie, activez Advanced Cron Manager et ouvrez Outils → Cron Manager. Repérez le tableau des événements et celui des fréquences. Recherchez les mêmes tâches que dans le relevé WP Crontrol et notez leurs paramètres. L’écran permet de gérer des événements et des fréquences. Pendant l’inventaire, concentrez-vous sur la lecture. Modifier une fréquence pour rendre un essai plus rapide peut avoir un effet sur un autre traitement qui utilise la même fréquence.

Si les traces gratuites de WP Crontrol ne couvrent pas votre besoin, étudiez les outils Pro d’Advanced Cron Manager, notamment Cron Logger, Performance Stats et Debug Tool. Définissez précisément le manque à combler : mesure mémoire, données de diagnostic ajoutées par le développeur ou règle de programmation particulière. Sur la copie, comparez la trace d’une opération locale réversible au résultat attendu. Une ligne d’exécution indique un passage dans le traitement ; sa réussite technique ne prouve pas que la synchronisation externe a produit le bon contenu.

Pour un traitement qui échoue, relevez le nom, l’heure, l’environnement et la trace utile. Ne confondez pas une tâche qui ne part jamais avec une tâche qui se lance puis rencontre une erreur. Dans le premier cas, comparez la date, le mécanisme de lancement et la disponibilité de son action. Dans le second, demandez au responsable du traitement de vérifier ses entrées et sa dépendance externe. Une différence entre les deux sites peut venir d’une extension inactive, d’un autre accès ou d’un fichier manquant.

Après l’essai, remettez les réglages de journalisation à un niveau adapté. Les traces peuvent augmenter le volume de données et contenir des informations propres au site. Fixez leur période de conservation et leur accès. Si le besoin se limite à une comparaison d’événements, utilisez le socle gratuit et conservez un relevé ciblé au lieu de garder une observation détaillée au-delà de la migration.

• Repérer les événements et les fréquences dans Cron Manager.
• Évaluer le journal Pro avec une opération de test isolée.
• Comparer une trace d’exécution au résultat attendu.

Séparer les événements WordPress des autres files

Le planificateur de l’hébergement peut déclencher WordPress, mais il peut aussi lancer des scripts indépendants. Demandez un relevé de ces tâches au responsable de l’hébergement. Après la migration, vérifiez leur commande, leur utilisateur et leur destination. Si l’ancien planificateur appelle toujours l’ancien domaine ou une URL qui redirige désormais vers le nouveau site, le nombre de déclencheurs peut être différent de celui prévu. Consignez la source des appels avant de remettre les tâches en route.

Si WooCommerce ou une autre extension utilise Action Scheduler, examinez aussi sa propre liste d’actions planifiées. WP-Cron peut lancer le mécanisme qui dépile ces actions. Cela ne transforme pas la liste Cron Events en inventaire de chaque action en attente. Comparez séparément les tâches WordPress et les actions de la file applicative. Pour les traitements liés aux commandes, relevez les dernières actions réussies et les prochaines tâches importantes avant d’effectuer la copie finale.

Sur la copie, bloquez ou redirigez les opérations qui contacteraient des services réels. Le mode de maintenance visible dans le navigateur ne suspend pas forcément les appels d’un planificateur, les files de tâches ni les accès directs d’un prestataire. Vérifiez l’isolation avec la personne qui contrôle le serveur et les comptes externes. Gardez un seul environnement autorisé à traiter les données réelles à chaque étape de la bascule.

Si le site cible utilise un planificateur système, suivez la méthode documentée par l’hébergeur et WordPress. Coordonnez l’activation du nouvel appel et l’arrêt de l’ancien. Un réglage qui empêche le déclenchement lors des visites ne remplace pas l’appel prévu par le planificateur. Faites un contrôle de bout en bout avant de considérer la migration terminée.

• Relever les appels du serveur et les files applicatives.
• Préparer l’arrêt de la source et l’activation de la cible.
• Vérifier qu’un seul site exécute les traitements réels.

Comparer la licence et le besoin de traces

Au 4 novembre 2026, WP Crontrol et Advanced Cron Manager sont proposés gratuitement dans le répertoire WordPress. WP Crontrol 2.0.0 comprend désormais journalisation et Cron Insights sans achat Pro. Le parcours Advanced Cron Manager gratuit couvre l’inventaire et la gestion des événements ; ses diagnostics avancés restent présentés dans Pro. Choisissez la fonction nécessaire avant de comparer les licences. Ne fondez pas un achat sur une ancienne comparaison qui attribue tous les journaux à l’option payante.

BracketSpace présente Advanced Cron Manager Pro comme une offre annuelle, avec plusieurs licences et un an de support et de mises à jour. La page publique consultée le 4 novembre 2026 affiche un chargement à la place des montants. Aucun prix précis, montant de renouvellement ou total fiscal n’est donc retenu. Demandez une proposition datée pour le nombre de sites utile avant de budgéter cette option. Le comparatif demeure exploitable pour les deux parcours gratuits ; il ne permet pas de chiffrer un achat Pro.

Le coût opérationnel vient du temps d’analyse et de conservation des traces. Pour une migration simple, deux exports bien datés et un contrôle de la file peuvent suffire. Pour un site dont les traitements durent longtemps ou envoient vers plusieurs services, la trace d’exécution peut justifier un suivi plus détaillé. Fixez à l’avance ce qui devra être visible après la bascule. Une mesure qui n’aide pas à décider si le traitement a réussi ajoute surtout du bruit.

Préparez le budget avec une ligne pour l’hébergement, une ligne pour le plugin si nécessaire et une ligne pour la personne qui compare les deux relevés. Gardez les comptes et données séparés. La décision d’achat dépend de l’utilité du journal et de la durée pendant laquelle l’équipe doit conserver cette visibilité.

• Choisir le niveau de trace nécessaire après la migration.
• Vérifier le prix annuel de l’option Pro si elle est retenue.
• Inclure la charge d’exploitation dans le budget.

Vérifier les versions sans confondre minimum et validation

Les métadonnées officielles archivées le 3 novembre et recoupées le 4 novembre 2026 indiquent WP Crontrol 2.0.0, WordPress 6.6 minimum et PHP 7.4 minimum, avec « testé jusqu’à » WordPress 7.1.4. Advanced Cron Manager 2.7.0 annonce WordPress 5.0 minimum, PHP 5.3 minimum et « testé jusqu’à » WordPress 6.9.11. Le minimum ancien d’Advanced Cron Manager ne recommande pas de conserver une ancienne version PHP. Il ne prouve pas non plus que toutes les versions plus récentes ont été éprouvées.

La page commerciale Pro présente ses propres prérequis et exige le plugin Advanced Cron Manager actif. Ne remplacez pas les prérequis du socle par ceux de cette page commerciale. Pour la cible prévue, notez séparément les versions de WordPress, PHP, du socle et de l’extension Pro éventuellement achetée. L’écart entre la version WordPress du site et la borne déclarée dans le répertoire doit rester visible dans la décision. Il appelle une recette sur la copie, et ne permet à lui seul de conclure ni à une panne ni à une compatibilité.

Conservez aussi les extensions qui enregistrent les fréquences et les fonctions de rappel. Advanced Cron Manager précise que les fréquences personnalisées qu’il ajoute ne restent disponibles que lorsqu’il est actif, alors que les événements créés subsistent après sa désactivation. Retirer l’outil d’inventaire peut donc affecter un site auquel on a ajouté une fréquence pendant les essais. Pour une simple migration, évitez de créer une nouvelle fréquence ; si elle est nécessaire, documentez son propriétaire et vérifiez sa présence après tout retrait du plugin.

Sur une copie multisite, commencez par un site identifié et son contexte d’administration. Ne déduisez pas qu’un seul écran résume toutes les tâches de chaque sous-site. De même, un outil qui prend en charge le déclencheur d’Action Scheduler ne remplace pas le relevé de ses actions applicatives. Ces contrôles de périmètre sont des points de recette proposés, pas des résultats observés dans une installation. Aucune tâche, migration ou mesure de performance n’a été exécutée pour ce comparatif.

• Relever les versions du socle, de Pro et de la cible.
• Vérifier qui fournit chaque fréquence personnalisée.
• Établir le périmètre par site et par file avant la comparaison.

Basculer une fois et pouvoir réattribuer les traitements

Juste avant la bascule, notez l’heure de référence, les dernières opérations terminées et les événements en attente. Fermez les entrées que l’ancien site ne doit plus traiter. Vérifiez l’arrêt de ses déclencheurs et rapprochez la liste des tâches avec le relevé final de la cible. Une migration de domaine ou de serveur peut aussi déplacer le chemin d’un script ou l’accès à une dépendance. Confirmez que le nouveau site appelle la bonne destination avant de traiter des demandes réelles.

Autorisez d’abord les traitements dont vous pouvez observer l’effet. Consultez leur échéance et le résultat métier, puis vérifiez que la source n’a pas produit la même action. Si une tâche ne tourne pas, cherchez son état et son origine avant de la forcer. Un lancement manuel pourrait envoyer deux messages ou créer deux écritures si le traitement précédent est encore en cours. Gardez l’heure et l’identifiant de chaque opération vérifiée.

Si vous devez revenir à l’ancien site, arrêtez d’abord les déclencheurs de la cible. Comparez ce qu’elle a exécuté avec ce que la source a encore en attente. Décidez quelles opérations doivent être reprises, ignorées ou rapprochées par l’équipe. Ne réactivez pas automatiquement tous les événements de la source après un retour du trafic. Le retour au site précédent ne remet pas à zéro les actions déjà envoyées à un service externe.

Une fois la situation stable, conservez le relevé, la méthode de déclenchement et les preuves des opérations importantes. La prochaine personne qui déplacera le site pourra identifier les tâches sensibles et savoir où vérifier leurs effets. Retirez les outils d’observation temporaires selon la procédure de l’équipe seulement après avoir récupéré les traces utiles.

• Prendre un relevé final au moment de la bascule.
• Vérifier l’exécution et son effet sur un seul environnement.
• Rapprocher les opérations déjà réalisées avant tout retour.

Rétablir un événement identifié sans réinjecter toute la file

Imaginons qu’après la copie un traitement de synchronisation n’apparaisse plus. Retrouvez son hook, ses arguments exacts, sa fréquence et son propriétaire dans le relevé initial. Vérifiez d’abord si son extension est active et configurée sur la cible. Si elle dispose d’une commande de réparation de sa programmation, utilisez son parcours documenté sur la copie et observez la ligne créée. Ajouter manuellement un événement sans fonction de rappel disponible ne restaure pas le traitement ; cela ajoute seulement une échéance qui restera inexploitable.

Si seule une date ou une pause a été modifiée par l’équipe, revenez sur cette même ligne et remettez la valeur ou l’état relevé avant l’essai, avec l’outil qui le permet. Comparez les arguments avant de valider. Une fréquence partagée ne doit pas être modifiée pour corriger un seul événement sans relever les autres utilisateurs de cette fréquence. Si la tâche a déjà produit un effet extérieur, rapprochez cet effet avant de reprogrammer : rétablir une échéance dans WordPress n’annule ni un fichier envoyé ni une commande traitée.

Le CSV d’inventaire n’est pas une sauvegarde restaurable de la file. Évitez également de remplacer globalement l’état cron de la base par une ancienne valeur : des événements légitimes ont pu apparaître pendant la migration. Préférez le mécanisme de l’extension propriétaire, ou une intervention ciblée préparée par son responsable. Conservez pour chaque correction la ligne avant, la ligne après, l’heure et la justification. Si le responsable ne peut pas identifier l’événement, laissez le traitement suspendu dans le périmètre prévu et faites analyser son origine.

Pour clôturer la recette, choisissez une publication de démonstration et une synchronisation vers une destination de test. Vérifiez leur effet sur la cible, puis assurez-vous que la source ne l’a pas reproduit. Comparez les dernières opérations terminées avec les prochaines échéances ; une date avancée seule ne prouve pas une réussite métier. En cas de retour au site précédent, suspendez la cible avant de lui retirer le trafic et attribuez explicitement à la source les seules opérations restant à reprendre. Le basculement du DNS ne constitue pas cette attribution.

• Identifier le hook et les arguments avant toute correction.
• Utiliser d’abord la réparation prévue par le composant propriétaire.
• Rapprocher les effets externes avant une nouvelle exécution.

Pour aller plus loin

• Choisir un outil de migration WordPress
• Diagnostiquer les tâches de fond en retard