Actions planifiées WooCommerce en attente ou en échec : diagnostiquer le retard avant de supprimer les tâches

Ce que représentent réellement les actions planifiées WooCommerce

Action Scheduler est un système de traitement en arrière-plan utilisé dans tout l’écosystème WooCommerce.

Une action planifiée ne représente pas automatiquement des données de maintenance.

Selon la boutique et les extensions installées, le travail planifié peut représenter :

• le traitement de paiements
• le renouvellement d’abonnements
• des e-mails client
• la livraison de webhooks
• la synchronisation du stock
• des imports
• des traitements analytiques
• des migrations de base de données
• des nouvelles tentatives d’intégration
• des opérations de nettoyage
• des tâches de plugins personnalisés

Une ancienne action Pending peut donc représenter un travail métier inachevé.

Avant de modifier la file, déterminez ce que font réellement les actions dominantes.

L’écran accessible dans :

WooCommerce → Status → Scheduled Actions

permet d’examiner les actions par état, hook, date prévue et groupe, et de consulter les journaux associés aux échecs.

Ces détails sont bien plus utiles que le nombre global affiché.

Pending, en retard et Failed ne signifient pas la même chose

Une erreur fréquente consiste à traiter toutes les actions non terminées comme un même problème.

Ce n’est pas le cas.

Actions Pending prévues dans le futur

Il s’agit normalement de tâches planifiées qui attendent leur heure d’exécution prévue.

Une file contenant des actions Pending n’est donc pas automatiquement en mauvais état.

Actions Pending en retard

L’heure prévue est passée, mais l’action n’est pas terminée.

Quelques actions légèrement en retard peuvent survenir.

Une accumulation croissante d’anciennes actions en retard nécessite une investigation.

Les questions utiles sont :

• Quelle est l’ancienneté de l’action en retard la plus ancienne ?
• Cette ancienneté augmente-t-elle ?
• Des actions continuent-elles à se terminer ?
• Quels hooks dominent les actions en retard ?

Actions en échec

Une action Failed a été tentée, mais n’a pas abouti selon le cycle d’exécution d’Action Scheduler.

Le journal devient alors important.

Des échecs répétés d’un même hook racontent une autre histoire que des milliers d’échecs historiques sans rapport.

Actions en cours

Elles méritent de l’attention si elles semblent rester actives bien plus longtemps que ce que nécessite raisonnablement la tâche.

Explications possibles :

• travail lent
• arrêt du processus
• dépassement de délai
• latence d’une API externe
• contention en base de données
• défaillance d’un worker

Le cycle documenté d’Action Scheduler considère qu’une action exécutée depuis plus de cinq minutes a dépassé son délai et peut la marquer Failed. Si le callback aboutit ensuite, l’état peut passer à Complete.

Ne diagnostiquez pas le système uniquement à partir de l’étiquette d’état.

Corrélez cet état aux horodatages et aux journaux.

Ne pas mesurer le fonctionnement de la file seulement par son volume total

Supposons qu’une boutique ait 20 000 actions planifiées.

Ce nombre seul n’établit pas de problème.

Supposons maintenant que :

• 19 500 sont des enregistrements historiques terminés.
• 450 sont des tâches futures légitimes.
• 50 sont actuellement arrivées à échéance.

Comparons avec :

• 18 000 sont en retard de trois jours.
• 1 500 sont à l’état Failed.
• L’horodatage Pending le plus ancien s’éloigne davantage dans le passé à chaque heure.

Le second système présente un problème actif de file.

Une meilleure évaluation d’Action Scheduler repose sur au moins cinq dimensions.

1. Ancienneté

Mesurez le retard des tâches arrivées à échéance. Relevez :

• l’action Pending en retard la plus ancienne
• l’action en retard la plus récente
• la répartition approximative des anciennetés

Une file qui conserve quinze secondes de retard diffère d’une file contenant des tâches qui auraient dû s’exécuter trois jours auparavant.

2. Débit

Observez la file sur un intervalle et vérifiez si le travail terminé progresse.

Si oui, le processus d’exécution peut être actif, mais sous-dimensionné.

Si aucune action significative ne se termine, examinez le déclenchement, l’exécution des workers ou les échecs répétés.

3. Rythme d’arrivée

Mesurez la vitesse d’arrivée des nouvelles tâches.

Une file peut fonctionner normalement et pourtant croître si un plugin planifie les tâches plus vite que les workers disponibles ne les traitent.

Sur le plan conceptuel :

nouvelles tâches arrivées à échéance → capacité de traitement → tâches terminées

Si les arrivées dépassent durablement le débit réussi, l’ancienneté et le volume du retard augmentent.

Ajouter des workers peut parfois améliorer la situation.

Mais si un composant produit soudain dix fois plus de tâches que prévu, augmenter la capacité peut seulement accélérer un travail inutile.

Identifiez le producteur autant que le processus d’exécution.

4. Concentration des échecs

Vérifiez si les actions échouées partagent un hook, un groupe ou une erreur. Une seule action en échec dit peu de choses.

Un millier d’actions présentant les mêmes caractéristiques d’échec :

• hook
• plugin
• erreur d’API
• dépassement de délai
• erreur d’authentification
• exception

constituent un signal de diagnostic fort.

Regroupez les échecs par opération représentée. La question utile est de savoir quel parcours échoue à répétition, pas pourquoi Action Scheduler contient des lignes Failed.

5. Effet métier

Identifiez enfin l’opération métier représentée par chaque action. Cela détermine l’urgence et le plan de reprise.

Une actualisation analytique retardée n’équivaut pas à :

• un renouvellement d’abonnement retardé
• un webhook d’exécution de commande non envoyé
• une opération de paiement
• une tâche de synchronisation du stock

Le diagnostic d’une file nécessite un contexte métier.

Établir une fiche caractéristique de la file avant toute modification

Relevez une base succincte pour la boutique concernée.

Effectuez une autre observation après un intervalle adapté.

Vous en apprendrez bien plus qu’avec une seule capture affichant :

8 742 actions en retard.

Frontière d’échec 1 : la file n’est pas déclenchée de manière fiable

WooCommerce s’appuie normalement sur l’infrastructure de planification WordPress pour lancer les tâches de fond arrivées à échéance.

Si WP-Cron est désactivé sans remplacement adapté, ne peut pas être lancé de façon fiable ou voit ses requêtes bloquées, les tâches planifiées peuvent rester en retard.

Vérifiez :

• si WP-Cron a été désactivé intentionnellement
• si une tâche Cron réelle côté serveur l’a remplacé
• si les événements Cron continuent à se déclencher
• si les requêtes de bouclage fonctionnent
• si l’authentification HTTP, le pare-feu ou les règles de sécurité interfèrent
• si le site dépend entièrement du déclenchement de WP-Cron par le trafic

Mais ne faites pas de :

retard Action Scheduler = WP-Cron défectueux

votre conclusion automatique.

Par défaut, Action Scheduler est lancé par WP-Cron et peut également démarrer le traitement depuis le hook shutdown des requêtes WP Admin. Il ne dépend toutefois pas exclusivement de WP-Cron : d’autres mécanismes d’exécution peuvent aussi lancer la file.

Une file qui termine lentement son travail présente manifestement un autre problème qu’une file qui ne s’exécute jamais.

Déterminez si le déclenchement est réellement absent avant de le remplacer.

Frontière d’échec 2 : la file fonctionne, mais son débit est trop faible

C’est une distinction importante.

Si des actions se terminent mais que l’échéance en retard la plus ancienne s’éloigne toujours davantage, le système peut traiter correctement le travail, sans le faire assez vite.

La documentation d’Action Scheduler décrit des valeurs par défaut prudentes destinées aux hébergements courants.

Le processus web standard actuel utilise une fenêtre de traitement de 30 secondes, réserve 25 actions par lot et autorise un seul lot simultané. Ces valeurs sont volontairement prudentes pour les environnements d’hébergement inconnus.

Ces valeurs par défaut répondent à un objectif de sûreté.

Ce ne sont pas des objectifs de performance valables pour chaque boutique.

Un système WooCommerce à fort volume peut nécessiter une architecture de traitement de file plus délibérément dimensionnée.

Mais n’augmentez pas immédiatement :

• le temps d’exécution
• la taille des lots
• le nombre de processus d’exécution concurrents
• simplement parce que la file est volumineuse

Action Scheduler avertit explicitement qu’augmenter les lots concurrents peut accroître fortement la charge serveur et provoquer une indisponibilité du site.

La concurrence peut aussi accroître la contention lorsque plusieurs tâches utilisent les mêmes ressources de base de données.

Avant d’augmenter le débit, répondez à ces questions :

• Combien de temps prend une action moyenne du type dominant ?
• Le travail est-il limité par le processeur, la base ou le réseau ?
• Les actions peuvent-elles s’exécuter simultanément sans risque ?
• L’API externe impose-t-elle des limites de débit ?
• La base présente-t-elle de la contention ?
• Le producteur génère-t-il une quantité de travail raisonnable ?

La capacité de la file doit correspondre aux caractéristiques de la charge.

Frontière d’échec 3 : le processus fonctionne, mais une tâche échoue continuellement

Supposons que la file soit active.

La plupart des tâches se terminent.

Mais un hook produit des milliers d’actions Failed.

Dans ce cas, le planificateur signale un échec applicatif.

Le planificateur fait son travail : il appelle la tâche et enregistre l’échec.

Examinez alors le callback.

Causes possibles :

• exceptions PHP
• état applicatif invalide
• enregistrements absents de la base
• identifiants expirés
• échec de l’API distante
• limitation de débit
• charges utiles inattendues
• incompatibilité d’une extension
• délais dépassés
• défauts dans le code personnalisé

Ouvrez l’action échouée et examinez son journal.

Recherchez ensuite un autre échec du même hook.

Si le schéma se répète, identifiez le plugin, l’intégration ou le composant personnalisé qui enregistre ce hook.

Cette correspondance est importante :

hook → responsable → fonction métier → dépendance → échec

Une fois cette chaîne connue, le planificateur devient une source d’observation plutôt que le suspect.

Frontière d’échec 4 : des dépendances externes ralentissent les workers

Les tâches de fond communiquent souvent avec d’autres systèmes.

Exemples :

• API de paiement
• plateformes d’expédition
• systèmes ERP
• systèmes CRM
• services de stock
• prestataires d’e-mail
• plateformes d’exécution des commandes

Si une action attend plusieurs secondes, voire des dizaines de secondes, un service distant, un petit nombre d’actions peut consommer une grande partie de la fenêtre de traitement du worker.

Recherchez :

• des délais de connexion dépassés
• des réponses API lentes
• des boucles de nouvelle tentative
• des limites de débit HTTP 429
• des réponses HTTP 5xx
• des échecs d’authentification

Ne cherchez pas à résoudre la latence d’une dépendance distante en multipliant aveuglément la concurrence.

Si le service récepteur impose une limite de débit, davantage de workers parallèles peuvent aggraver l’échec.

C’est là que l’ingénierie de plugins et d’intégrations WooCommerce sur mesure compte : l’opération mise en file nécessite un modèle d’échec délibéré autant qu’un planificateur.

Une intégration robuste doit définir :

• le comportement en cas de délai dépassé
• la politique de nouvelle tentative
• les limites des nouvelles tentatives
• l’idempotence
• l’état d’échec
• le rapprochement

Une file relève de l’infrastructure.

L’opération qu’elle contient nécessite toujours une conception d’intégration fiable.

Frontière d’échec 5 : un producteur planifie trop de travail

Parfois, rien n’est défectueux dans le processus d’exécution.

Le problème se situe en amont.

Un plugin, un import ou un parcours personnalisé peut créer des actions à un rythme anormalement élevé.

Recherchez :

• un hook dominant les actions Pending
• des tâches récurrentes planifiant des doublons
• un import planifiant à répétition une action pour chaque enregistrement
• des tâches replanifiées avant la fin du travail existant
• une migration générant continuellement de nouveaux lots
• du code personnalisé planifiant depuis un callback sans contrôle d’unicité adapté

Action Scheduler permet de planifier des actions uniques.

La génération actuelle 4.0 a aussi modifié le comportement d’unicité : les arguments participent désormais à la détermination d’un doublon pour une action qui correspond par ailleurs.

Il est donc important de connaître la version installée pour examiner une logique de planification personnalisée.

La question de fond reste :

Devrait-il seulement exister autant d’actions ?

Un processus d’exécution plus rapide ne remplace pas la correction d’un producteur devenu incontrôlé.

Un retard de file et un nettoyage de base sont des incidents distincts

L’article #3 abordait un incident lié, mais distinct :

la croissance inattendue de la base WooCommerce.

Les tables Action Scheduler peuvent contribuer fortement à la taille de la base, notamment dans les boutiques qui traitent beaucoup de tâches de fond.

Mais :

Une table Action Scheduler volumineuse et un retard actif de file ne constituent pas le même incident.

Une table peut être volumineuse à cause d’enregistrements historiques terminés ou échoués alors que le traitement courant fonctionne correctement.

Une file peut être très en retard tout en ayant des tables relativement petites.

Gardez donc les questions distinctes :

Si la base elle-même grossit de manière inattendue, suivez l’investigation plus large : croissance inattendue de la base WooCommerce plutôt que de supprimer la file comme stratégie de nettoyage de la base.

Action Scheduler 4.0 a modifié le comportement de nettoyage

Le contexte de version compte désormais davantage qu’auparavant.

Historiquement, Action Scheduler supprimait les anciennes actions Complete et Canceled, mais conservait par défaut indéfiniment les actions Failed.

Action Scheduler 4.0 a changé ce comportement.

Les actions Failed sont désormais éligibles au nettoyage automatique après trois mois par défaut. La maintenance a été remaniée en un processus quotidien dédié capable de poursuivre le traitement d’un retard de nettoyage.

Les anciens articles décrivant les actions Failed comme conservées indéfiniment par défaut peuvent donc ne plus refléter l’implémentation actuelle.

Avant de modifier la conservation, déterminez :

• la version d’Action Scheduler réellement exécutée
• si une extension embarque une autre copie ou une copie actuelle
• si des filtres personnalisés modifient la conservation
• si la maintenance elle-même s’exécute correctement

N’ajoutez pas de code de nettoyage personnalisé pour corriger un comportement que le planificateur actuel gère déjà correctement.

Ne pas supprimer des actions Pending simplement parce qu’elles sont anciennes

C’est l’une des règles de prudence les plus importantes.

Une action Pending peut représenter un travail qui n’a pas encore eu lieu.

La supprimer peut transformer

un travail visiblement retardé

en :

un travail abandonné silencieusement.

Avant de supprimer une action Pending, établissez :

• quel composant l’a créée
• quelle opération métier elle représente
• si l’opération a déjà eu lieu par un autre parcours
• si elle est toujours nécessaire
• si l’exécuter maintenant pourrait produire un effet de bord indésirable
• si l’application la recréera

Les exemples comptent.

Une tâche obsolète de rafraîchissement de cache diffère fortement d’un paiement de renouvellement en retard.

Un ancien import analytique diffère fortement d’un callback d’exécution de commande.

L’état n’indique pas la valeur métier.

Faire preuve de la même prudence lors de l’exécution manuelle du retard

Tout exécuter n’est pas automatiquement plus sûr que tout supprimer.

Imaginez que la file se soit arrêtée deux jours auparavant.

Pendant ces deux jours, elle a accumulé :

• des paiements de renouvellement
• des e-mails client
• des mises à jour d’intégration
• des webhooks
• la synchronisation du stock

Le déclenchement est maintenant rétabli.

Le travail en file peut commencer à s’exécuter.

Cette reprise peut elle-même produire une charge opérationnelle ou une activité métier inattendue.

Donc :

Traitez la reprise du retard comme un événement de production.

Avant de résorber une file importante, comprenez :

• ce qui sera exécuté
• si ces opérations restent valides
• si elles sont idempotentes
• si les clients pourraient recevoir des messages périmés
• si les opérations de paiement doivent être examinées
• si les intégrations peuvent absorber le rythme de rattrapage
• si le serveur a la capacité d’absorber la pointe

À grande échelle, les outils WP-CLI d’Action Scheduler permettent de traiter certains hooks ou groupes afin de gérer délibérément différentes catégories de travail.

C’est utile sur le plan opérationnel, mais pas automatiquement sûr. La documentation WP-CLI avertit qu’un filtrage par hook ou groupe peut rompre les dépendances d’ordre implicites entre des actions normalement exécutées selon leur planification.

N’utilisez une reprise filtrée que si vous comprenez ces dépendances.

Cela renforce le principe suivant :

ne traitez pas toutes les tâches en file comme un travail équivalent.

Pourquoi augmenter la concurrence peut être dangereux

Face à un retard, ajouter des workers semble être une réponse évidente.

C’est parfois le cas.

Mais considérons trois tâches qui actualisent simultanément les mêmes enregistrements de commande en base.

Ou trois workers API qui atteignent tous la même limite de débit externe.

Ou plusieurs processus de fond coûteux qui disputent au tunnel client les workers PHP et la capacité de la base.

La documentation d’Action Scheduler avertit explicitement que multiplier les lots concurrents peut augmenter la charge jusqu’à rendre le site indisponible.

• Avant d’ajuster la concurrence :
• profilez le travail dominant.
• comprenez les ressources de base partagées.
• comprenez les limites distantes.
• protégez la capacité de la boutique et du tunnel.
• augmentez progressivement.
• mesurez après chaque changement.

Les traitements de fond doivent améliorer la fiabilité pour les clients, pas consommer toutes les ressources dont ils ont besoin. Si la pression de la file entre en concurrence avec le tunnel, les workers PHP ou la base, abordez cet incident sous l’angle des performances WooCommerce et de la remise en service en production plutôt que comme un simple problème de nombre de tâches.

Distinguer une file arrêtée d’une file sous-dimensionnée

C’est l’une des classifications de diagnostic les plus utiles.

File arrêtée

Caractéristiques :

• l’ancienneté du retard augmente continuellement.
• aucune action significative ne se termine.
• le déclenchement du processus peut être absent ou défaillant.
• les journaux d’exécution peuvent s’arrêter complètement.

À examiner :

déclenchement → processus d’exécution → capacité à démarrer le travail

File sous-dimensionnée

Caractéristiques :

• des actions se terminent.
• le nombre d’actions Pending reste élevé ou augmente.
• l’échéance la plus ancienne peut continuer à s’éloigner dans le passé.
• les nouvelles tâches arrivent plus vite que le débit de réussite.

À examiner :

rythme d’arrivée → durée des actions → capacité des workers → concurrence → volume produit

File en échec

Caractéristiques :

• le processus d’exécution est actif.
• un ou plusieurs hooks atteignent à répétition l’état Failed.
• les erreurs et journaux montrent des défaillances applicatives ou de dépendances.

À examiner :

hook → callback → dépendance → erreur

File suralimentée

Caractéristiques :

• le worker peut fonctionner correctement.
• un producteur planifie beaucoup plus de travail que prévu.
• le volume Pending augmente malgré un débit raisonnable.

À examiner :

producteur → logique de planification → unicité → récurrence

Cette distinction en quatre catégories réduit fortement le dépannage au hasard.

Une séquence pratique de diagnostic

Pour un incident Action Scheduler en production, suivez cet ordre.

1. Préserver les éléments observés

   Relevez :

   • les nombres par état
   • l’échéance en retard la plus ancienne
   • les hooks dominants
   • les groupes dominants
   • des exemples de journaux d’échec
   • les versions actuelles de WooCommerce et d’Action Scheduler
   • les changements récents

   Faites-le avant toute suppression ou annulation massive.

2. Identifier le travail métier

   Reliez les hooks dominants aux plugins ou intégrations qui en sont responsables.

   Déterminez si les actions représentent :

   • un paiement
   • une communication au client
   • l’exécution d’une commande
   • une synchronisation
   • les analyses
   • un nettoyage
   • une migration
   • une opération personnalisée

   Cela établit le risque.

3. Vérifier si la file progresse

   Observez-la dans le temps.

   Suivez la poursuite des réussites, l’amélioration de l’ancienneté du retard et la baisse du volume Pending. Cela distingue une file arrêtée d’une file trop lente.

4. Comparer les arrivées et le traitement

   Si les nouvelles tâches arrivent plus vite qu’elles ne se terminent, déterminez si :

   • la capacité de traitement est insuffisante.
   • la durée des actions est anormale.
   • un producteur génère trop de travail.

5. Examiner les échecs répétés

   Choisissez des actions Failed représentatives parmi les hooks dominants.

   Lisez leurs journaux d’exécution.

   Corrélez-les avec :

   • les journaux WooCommerce
   • les erreurs PHP et serveur
   • les notes de commande lorsque cela convient
   • les journaux des prestataires distants
   • les réponses d’intégration

6. Établir une catégorie d’échec

   Déterminez si le problème principal concerne :

   • le déclenchement
   • la capacité
   • un échec de callback
   • une dépendance
   • une surproduction

   Plusieurs problèmes peuvent coexister, mais identifiez-les indépendamment.

7. Corriger la frontière responsable

   Exemples :

   • rétablir un déclenchement fiable de la file.
   • corriger une exception.
   • corriger des identifiants API expirés.
   • borner un délai externe.
   • arrêter la planification en double.
   • reconcevoir une tâche trop volumineuse.
   • augmenter prudemment la capacité de traitement.

   Ne modifiez pas cinq variables sans rapport en même temps.

8. Reprendre le retard de manière délibérée

   Avant d’exécuter d’anciennes tâches, déterminez si elles sont :

   • nécessaires
   • obsolètes
   • dangereuses à rejouer
   • à rapprocher d’abord

   Pour les actions commercialement sensibles, vérifiez le système externe avant de rejouer.

9. Vérifier le parcours métier

   Ne vous arrêtez pas à :

   nombre d’actions Pending = 0.

   Vérifiez ce que les actions étaient censées accomplir.

   Par exemple :

   • le paiement de renouvellement a eu lieu une seule fois.
   • l’état de commande est correct.
   • l’e-mail a été envoyé correctement.
   • le système d’exécution a reçu le bon état.
   • le stock a été synchronisé.
   • l’état de l’API externe a été rapproché.

10. Vérifier le fonctionnement durable de la file

    Continuez à observer.

    Une reprise saine doit montrer :

    • une ancienneté du retard qui revient vers la normale
    • des tâches qui continuent à se terminer
    • la disparition du schéma d’échec récurrent
    • un équilibre durable entre arrivées et travail terminé
    • aucune saturation serveur inattendue
    • aucune opération en double en aval

Une file vide n’est pas une vérification suffisante

Supposons que vous supprimiez 50 000 actions Pending.

La file paraît désormais parfaite.

Supprimer les lignes change l’indicateur tandis que la défaillance sous-jacente demeure.

De même, supposons que vous forciez l’exécution de chaque action.

Le nombre tombe à zéro.

Mais vingt clients reçoivent des messages en double et une intégration traite deux fois les événements historiques.

Le nombre de tâches s’est rétabli alors que le parcours métier a échoué.

La bonne question de vérification est :

Les nouvelles tâches planifiées sont-elles créées au rythme attendu, exécutées dans un délai acceptable, correctement terminées et produisent-elles chaque effet métier prévu sans risque ?

C’est un critère de fonctionnement bien plus solide que le nombre de tâches.

Prévenir le prochain retard

Pour les processus de fond WooCommerce importants, surveillez les caractéristiques qui révèlent une dégradation précoce.

Les signaux utiles comprennent :

• l’ancienneté du retard le plus ancien
• le nombre d’actions Pending arrivées à échéance
• les actions Failed par hook
• la signature d’erreur récurrente
• le débit de terminaison
• le rythme de création des actions
• les tâches anormalement lentes
• la croissance des tables de file
• la pression sur les ressources PHP et de base de données
• les échecs d’API externes

Les tâches de fond personnalisées doivent également prévoir des réponses explicites concernant :

• l’idempotence
• délais dépassés
• les nouvelles tentatives
• les limites des nouvelles tentatives
• la journalisation
• l’état d’échec
• la conservation des données
• le rapprochement

Action Scheduler fournit l’infrastructure d’exécution.

Il ne peut pas rendre fiable, à lui seul, une logique métier qui ne l’est pas.

Quand faire appel à une expertise spécialisée

Une investigation spécialisée est justifiée lorsque :

• les actions en retard continuent d’augmenter.
• les renouvellements, e-mails, webhooks ou intégrations sont retardés.
• WP-Cron semble actif, mais la file reste en retard.
• la file traite une partie du travail sans jamais rattraper le retard.
• un hook génère des milliers d’échecs.
• une API externe rend les tâches lentes ou peu fiables.
• les tables Action Scheduler grossissent rapidement.
• augmenter les limites serveur n’a pas permis d’établir une cause.
• des plugins personnalisés produisent de grandes files récurrentes.
• la reprise pourrait rejouer des opérations commercialement sensibles.
• un nettoyage antérieur a supprimé des actions sans résoudre leur réapparition.

L’objectif ne doit alors pas être :

vider les actions planifiées.

Il doit être de :

déterminer si la file n’est pas déclenchée, est sous-dimensionnée, en échec ou suralimentée ; corriger cette frontière, reprendre sans risque le travail métier en attente et démontrer que les nouvelles tâches s’exécutent normalement.