# Un chien de garde pour vérifier qu’une tâche planifiée tourne vraiment > Plutôt que de surveiller que le serveur tourne, un ping attendu à intervalle régulier révèle qu'une tâche censée s'exécuter a discrètement cessé de le faire. Mise en place concrète. - Auteur : Clément Hadrot - Publié le : 2024-11-25 - Mis à jour le : 2024-11-25 - Catégorie : Outils & workflow - URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/chien-de-garde-tache-planifiee-wordpress/ ## L’essentiel - Un serveur disponible ne garantit pas qu'une tâche planifiée s'exécute réellement - Un chien de garde attend un signal régulier plutôt que de vérifier un état - L'absence de signal, plutôt qu'une erreur explicite, déclenche l'alerte Onze jours. C'est la durée pendant laquelle une tâche de sauvegarde quotidienne, exécutée via une entrée `cron` système censée appeler un script WP-CLI chaque nuit, a silencieusement cessé de s'exécuter sur un projet, sans qu'aucune alerte ne se déclenche — parce que la supervision en place vérifiait uniquement que le serveur répondait, jamais que la tâche elle-même avait effectivement tourné. La cause de l'arrêt tenait à une modification du chemin d'un script lors d'une réorganisation du projet, sans mise à jour correspondante de l'entrée `cron` qui continuait de pointer vers l'ancien emplacement. La commande échouait silencieusement chaque nuit, sans que rien ne remonte cette erreur puisque personne ne surveillait spécifiquement ce point précis. ## Pourquoi surveiller le serveur ne suffit pas La supervision classique d'un serveur vérifie sa disponibilité, sa charge, l'espace disque restant : autant d'indicateurs pertinents, mais qui ne disent rien du succès ou de l'échec d'une tâche planifiée précise exécutée sur ce serveur. Un serveur parfaitement disponible peut héberger une tâche `cron` qui échoue silencieusement depuis des jours, sans que le moindre indicateur de disponibilité générale ne s'en trouve affecté. ## Le principe du chien de garde applicatif Un chien de garde, ou *dead man's switch* en anglais dans la littérature technique mais que l'on peut décrire simplement comme un signal de vie attendu à intervalle régulier, inverse la logique de surveillance habituelle. Plutôt que de vérifier activement qu'un état est correct, il attend passivement qu'un signal lui parvienne à intervalle régulier, et déclenche une alerte précisément quand ce signal n'arrive pas — c'est-à-dire quand quelque chose s'est arrêté sans prévenir. ## Mise en place concrète avec un script WP-CLI La tâche de sauvegarde, définie comme une commande WP-CLI personnalisée, envoie désormais une requête HTTP vers un service de contrôle externe dès qu'elle se termine avec succès : ``` #!/usr/bin/env bash set -euo pipefail wp --path=/var/www/site db export /var/backups/site-$(date +%F).sql wp --path=/var/www/site backup:televerser /var/backups/site-$(date +%F).sql curl -fsS --retry 3 "https://controle.exemple.fr/ping/identifiant-unique-du-site" ``` > L'essentiel à retenir : Un serveur disponible ne garantit pas qu'une tâche planifiée s'exécute réellement ; Un chien de garde attend un signal régulier plutôt que de vérifier un état ; L'absence de signal, plutôt qu'une erreur explicite, déclenche l'alerte Le service de contrôle externe attend de recevoir cette requête au moins une fois toutes les vingt-quatre heures. Si aucune requête n'arrive dans ce délai, il déclenche une alerte — par courriel ou par une notification vers un canal d'équipe — signalant que la tâche attendue ne s'est pas exécutée, ou du moins pas jusqu'à son terme, puisque la requête n'est envoyée qu'après la réussite complète des étapes précédentes. ## Pourquoi placer la requête à la fin, pas au début Un piège fréquent consiste à placer l'appel de confirmation en tout début de script, ce qui confirmerait uniquement que le script a démarré, pas qu'il s'est terminé avec succès. Grâce à `set -euo pipefail`, toute commande en échec interrompt le script avant d'atteindre la ligne finale d'appel au service de contrôle, garantissant que ce signal ne part effectivement que lorsque toutes les étapes précédentes ont réussi. ## Ce que ce dispositif a permis de détecter ensuite Après la mise en place de ce chien de garde sur l'ensemble des tâches planifiées critiques du parc — sauvegardes, purges de caches programmées, synchronisations de flux de contenu — trois incidents similaires ont été détectés en quelques mois, chacun en moins d'une journée après l'arrêt effectif de la tâche concernée, contre onze jours pour l'incident initial qui a motivé cette mise en place. - Un signal attendu à intervalle régulier, envoyé uniquement en fin d'exécution réussie - Une alerte déclenchée par l'absence du signal, pas par un message d'erreur explicite - Un identifiant unique par tâche surveillée, pour distinguer précisément laquelle a cessé de fonctionner ## Ce que ce mécanisme ne remplace pas Ce dispositif détecte qu'une tâche ne s'exécute plus ; il ne remplace pas une supervision générale du serveur qui l'héberge, qui reste nécessaire pour détecter d'autres classes de problèmes — saturation de ressources, indisponibilité réseau — sans rapport direct avec l'exécution d'une tâche planifiée précise. ## En résumé Un chien de garde applicatif, fondé sur l'attente d'un signal régulier plutôt que sur la vérification active d'un état, comble un angle mort fréquent de la supervision d'infrastructure : celui des tâches planifiées qui cessent de s'exécuter sans jamais produire d'erreur visible par ailleurs. La mise en place, une simple requête HTTP ajoutée en fin de script, coûte quelques minutes et referme un risque qui, sans cela, peut rester silencieux pendant des jours entiers.