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"
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.
