Un module qui doit tourner sans personne devant

Ce qui distingue un traitement de fond d’une page

Une page web est courte, déclenchée par un visiteur, et son échec est immédiatement visible. Un traitement de fond est long, déclenché par une horloge, et son échec ne se voit pas — sauf s’il a été prévu pour se signaler. C’est la différence la plus importante, et celle qui est le plus souvent négligée.

Il faut donc trois choses dès la conception. Un journal qui indique quand le traitement a démarré, ce qu’il a fait et pourquoi il s’est arrêté. Une protection contre le chevauchement, pour qu’une exécution qui dure plus longtemps que prévu n’en déclenche pas une seconde en parallèle sur les mêmes données. Et une reprise possible, pour qu’une interruption au milieu ne laisse pas la moitié du travail dans un état incertain.

Comment le déclenchement fonctionne réellement

Sur PrestaShop, un traitement périodique est un contrôleur appelé à intervalle régulier, soit par une tâche planifiée configurée sur le serveur, soit par un service extérieur qui appelle une adresse. La tâche planifiée du serveur est le mécanisme le plus fiable, parce qu’elle ne dépend d’aucun visiteur.

Sur WordPress, le mécanisme natif de planification est déclenché par le trafic : sans visite, rien ne se lance. Sur une boutique peu fréquentée, cela produit des traitements qui s’exécutent avec plusieurs heures de retard, ou pas du tout la nuit. La correction consiste à désactiver ce déclenchement par le trafic et à appeler le mécanisme depuis une tâche planifiée du serveur, à intervalle fixe. C’est l’une des interventions les plus rentables sur une boutique WooCommerce qui repose sur des traitements automatiques.

Dans les deux cas, l’adresse appelée doit être protégée : un traitement lourd déclenchable par n’importe qui devient un moyen simple de faire tomber le serveur.