Suivez les traitements planifiés avec une échéance métier, un résultat vérifiable et une procédure de reprise pour repérer les tâches absentes ou en retard.
L’import de stock doit être disponible à l’ouverture des bureaux. Aucun message d’erreur n’est arrivé pendant la nuit, mais les données affichées datent de la veille. Le processus n’a peut-être jamais démarré, ou il s’est terminé sans produire le résultat attendu. La supervision doit pouvoir détecter ces deux situations.
Pour chaque traitement, définissez ce que son destinataire attend et à quel moment. Un statut technique « terminé » peut suffire pour une tâche simple. Pour un import métier, il faut souvent confirmer que les données ont été contrôlées puis rendues disponibles au bon endroit.
Donner une identité à l’exécution attendue
Associez chaque lancement prévu à une période métier : journée de vente, clôture hebdomadaire ou lot reçu. Cette référence doit permettre de distinguer une exécution normale d’une reprise. Conservez aussi un identifiant propre à chaque tentative, pour suivre les relances sans écraser l’historique.
La fiche du traitement indique son calendrier, le fuseau utilisé et l’heure limite de disponibilité. Pour une équipe au Maroc travaillant avec un système externe, vérifiez explicitement comment les changements d’heure sont traités par les deux côtés. Un libellé tel que « chaque nuit » ne suffit pas à résoudre cette question.
Prévoyez le calendrier des jours sans traitement. Une absence attendue pendant une fermeture ne doit pas être interprétée comme une panne. À l’inverse, une exception temporaire ne doit pas continuer à suspendre les contrôles une fois l’activité reprise.
Séparer lancement, exécution et résultat métier
Enregistrez les transitions utiles à l’enquête. Le démarrage confirme que le programme a commencé ; il ne prouve pas qu’il a pu lire sa source. La fin du processus doit être rapprochée du résultat attendu pour la période traitée.
| État observé | Vérification proposée |
|---|---|
| Aucun lancement | Calendrier, ordonnanceur et autorisations |
| Exécution toujours active | Progression, dépendance et durée inhabituelle |
| Échec déclaré | Erreur et effets déjà produits |
| Fin annoncée sans résultat | Contrôle du fichier, des données ou de la publication |
| Résultat disponible | Période traitée et validation attendue |
La documentation Kubernetes sur les CronJobs précise que des circonstances peuvent conduire à des créations manquées ou répétées de Jobs et recommande des traitements idempotents. Elle décrit aussi des politiques de concurrence et la prise en compte du fuseau horaire. Vérifiez les garanties de votre ordonnanceur particulier, même si vous n’utilisez pas Kubernetes.
Surveiller l’absence avec un contrôle indépendant
Un programme qui ne démarre pas ne peut pas émettre son propre message d’échec. Prévoyez un contrôle qui examine la dernière exécution attendue et son résultat. Ce contrôle doit avoir un responsable et un chemin de notification vérifié.
Évitez de le faire dépendre exactement du même mécanisme dont vous voulez détecter la panne sans examiner ce risque. Si l’ordonnanceur est indisponible, votre dispositif doit pouvoir constater le résultat manquant depuis un autre point de contrôle adapté à votre architecture.
Vérifiez la fraîcheur de l’observation. Une page de supervision affichant un ancien statut vert peut donner l’impression que tout fonctionne. Montrez l’heure de la dernière vérification et traitez une observation trop ancienne comme une information incomplète.
Examiner les retards selon l’échéance métier
Un traitement peut durer davantage lorsque le volume augmente, tout en terminant avant l’heure requise. Conservez sa durée et le volume traité pour analyser cette évolution. L’alerte urgente doit correspondre au risque de manquer l’échéance ou à un blocage qui demande une action.
Définissez une marge permettant d’intervenir avant que les utilisateurs aient besoin du résultat. Si la reprise demande une nouvelle lecture complète de la source, intégrez ce délai dans la décision. Pour un traitement dont la durée varie fortement, préparez une mesure de progression exploitable.
La qualification des alertes d’exploitation aide à choisir le destinataire et l’action attendue. Le message doit mentionner la période concernée, la dernière tentative et le lien vers les informations utiles. Évitez une notification qui contient seulement le nom technique du programme.
Préparer une reprise sans répéter les effets métier
Avant de relancer, vérifiez ce que l’exécution précédente a déjà produit. Un import peut avoir enregistré une partie des lignes ; un export peut avoir transmis un fichier sans recevoir sa confirmation. La reprise doit suivre une règle propre au traitement.
Documentez le contrôle des doublons, les points de reprise disponibles et les cas qui demandent une intervention humaine. Si une exécution précédente est encore active, traitez ce conflit avant d’en démarrer une autre. Conservez la décision et l’identité de la personne qui l’a prise.
Pour les échanges entre applications, le guide sur les doublons d’intégration CRM et ERP détaille l’usage d’une référence d’opération stable. Ce principe doit être adapté aux effets réels de votre tâche, notamment lorsqu’elle appelle plusieurs services.
Tester les situations silencieuses
Dans un environnement isolé, simulez un lancement absent, une exécution bloquée et une fin sans résultat métier. Vérifiez que le contrôle désigne la bonne période et que le destinataire comprend l’action attendue. Les tests ne doivent pas déclencher des échanges réels avec les clients.
Faites ensuite rejouer une période de test selon la procédure de reprise. Contrôlez le résultat et l’absence de doublons, puis conservez les preuves dans la fiche du traitement. Reprenez cet exercice lorsque le calendrier, l’ordonnanceur ou une dépendance importante change.