Tâches planifiées dans un logiciel métier : éviter les traitements silencieusement bloqués

Une tâche planifiée doit avoir un état, un propriétaire, une limite de reprise et une preuve de résultat pour rester exploitable après un échec.

Les logiciels exécutent des imports, des relances, des exports et des rappels sans action directe de l’utilisateur. Un planificateur qui lance seulement une commande à une heure donnée ne suffit pas. Il faut savoir si la tâche a commencé, si elle a terminé et si une nouvelle tentative est sûre.

Décrire l’opération

Chaque tâche indique sa fréquence, son périmètre et sa dépendance. Une synchronisation peut traiter une entreprise précise ou toutes les entreprises. Une tâche globale doit enregistrer le contexte de chaque espace pour éviter une erreur de séparation.

Définissez le résultat attendu. « Envoi terminé » peut signifier que les messages ont été remis à un fournisseur ou que les utilisateurs les ont lus. Le logiciel doit nommer l’étape réellement vérifiée.

Gérer les reprises

Une panne réseau peut interrompre une tâche après l’écriture de plusieurs lignes. Enregistrez une clé d’opération et l’état de chaque élément. La relance doit ignorer ce qui est déjà terminé ou vérifier que l’effet est encore nécessaire.

Utilisez un nombre maximal de tentatives et un délai entre les reprises. Un service externe indisponible ne doit pas provoquer des centaines de demandes simultanées. Les éléments qui échouent toujours vont dans une file d’exception avec une raison exploitable.

Éviter les chevauchements

Une tâche lente peut encore fonctionner quand le planificateur lance l’exécution suivante. Utilisez un verrou ou une réservation avec une durée et un mécanisme de reprise. Le verrou doit se libérer après un arrêt afin de ne pas bloquer le traitement pendant des jours.

Le chevauchement peut être acceptable pour des opérations indépendantes. Décidez-le explicitement et vérifiez l’idempotence des écritures, comme pour les webhooks fiables.

Surveiller et alerter

Mesurez l’âge du dernier succès, la durée, le nombre d’éléments traités et le nombre d’échecs. Une alerte doit signaler une tâche absente autant qu’une tâche en erreur. L’équipe doit savoir qui intervient et comment relancer sans modifier les données à la main.

Les logs doivent contenir l’identifiant de tâche, l’entreprise, l’opération et le résultat sans recopier des données sensibles. Le journal d’audit conserve les actions métier importantes.

Sources : Google SRE, tâches et cron, AWS, bonnes pratiques de reprise.