Un retard moyen de quarante-sept minutes sur l’envoi de notifications censées informer les adhérents d’une coopérative agricole d’une variation de cours des matières premières : voilà le symptôme remonté par plusieurs adhérents, agacés de recevoir une alerte de prix largement après que le cours ait déjà évolué une nouvelle fois.
Symptôme : des notifications toujours en retard
Le site s’appuyait sur une tâche planifiée WordPress, déclenchée via wp_schedule_event(), censée s’exécuter toutes les cinq minutes pour vérifier les cours actualisés et notifier les adhérents concernés par un seuil de prix franchi. Or les notifications réellement envoyées accusaient un retard croissant au fil de la journée, particulièrement marqué en fin de matinée, moment où le trafic du site atteignait son pic quotidien.
Diagnostic : une mécanique qui dépend des visites
Le mécanisme de planification natif de WordPress, souvent appelé wp-cron, ne fonctionne pas comme un véritable service planifié du système d’exploitation : il se déclenche uniquement lors d’une requête HTTP reçue par le site, en vérifiant à cette occasion si une tâche planifiée est arrivée à échéance. Sur un site à trafic irrégulier, cela signifie que les tâches ne s’exécutent pas à intervalle strictement régulier, mais seulement quand un visiteur, un robot ou une requête quelconque déclenche le mécanisme.
Le second facteur aggravant tenait au volume : la coopérative avait sous-estimé le nombre d’adhérents à notifier par cycle, chaque exécution de la tâche parcourant une liste croissante d’abonnés aux alertes. Plus le trafic du site augmentait le nombre de déclenchements de wp-cron, plus le risque de chevauchement entre deux exécutions de la même tâche, encore en cours de traitement, augmentait également, chaque exécution ralentissant d’autant la suivante.
Correctif : un cron système fiable, en dehors du trafic
La première mesure a consisté à désactiver le déclenchement natif de wp-cron lié au trafic, via la constante DISABLE_WP_CRON, pour le remplacer par un appel système régulier, indépendant du nombre de visiteurs :
// wp-config.php
define( 'DISABLE_WP_CRON', true );
# Tâche système (crontab), toutes les cinq minutes exactement :
*/5 * * * * wget -q -O - https://cooperative-exemple.fr/wp-cron.php?doing_wp_cron >/dev/null 2>&1
Cette bascule garantit une exécution à intervalle fixe, indépendamment du trafic du site, y compris pendant les périodes creuses où aucun visiteur ne déclenchait auparavant le mécanisme natif. La seconde mesure a consisté à découper l’envoi des notifications en lots plus petits, traités sur plusieurs exécutions successives plutôt qu’en une seule passe sur l’ensemble des adhérents.
Prévention : surveiller la file, pas seulement l’exécuter
- Vérifier régulièrement, avec
wp cron event listen ligne de commande, l’absence d’accumulation de tâches en retard. - Dimensionner la fréquence d’une tâche planifiée en fonction du volume réel qu’elle doit traiter, pas d’une valeur choisie arbitrairement.
- Basculer systématiquement vers un cron système sur tout site où la ponctualité d’une tâche planifiée a une importance métier réelle.
Ce que ce correctif ne couvre pas
L’envoi de ces mêmes notifications via un webhook déclenché en temps réel par la source de cours, plutôt que par une vérification périodique, resterait une architecture différente, plus réactive mais nécessitant une intégration distincte non abordée ici.
Suivi mis en place après correction
Pour éviter qu’un problème similaire ne se reproduise silencieusement, une tâche de contrôle a été ajoutée : elle compare, chaque heure, le nombre de notifications qui auraient dû partir selon les seuils de prix franchis à celui réellement envoyé, et alerte l’équipe technique par courriel en cas d’écart. Ce filet de sécurité, ajouté après coup, aurait permis de détecter le problème initial bien avant que les adhérents ne le signalent eux-mêmes.
La coopérative a également profité de cette intervention pour documenter, dans un fichier de suivi interne, le volume attendu de notifications par cycle selon la saison, les envois se révélant nettement plus nombreux pendant les périodes de forte volatilité des cours que pendant les périodes calmes, une donnée qui n’avait jamais été formalisée avant cet incident.
Une tâche planifiée qui dépend du trafic du site pour s’exécuter n’est fiable que tant que personne n’en a réellement besoin en dehors des heures de forte affluence.
En résumé
Le retard des notifications de cours ne venait pas d’un défaut de logique métier, mais d’une dépendance mal comprise entre wp-cron et le trafic du site, aggravée par un volume de notifications sous-estimé au moment de la conception. Un cron système à intervalle fixe, combiné à un traitement par lots, a ramené la ponctualité des envois à un niveau conforme aux attentes des adhérents.
