Si WooCommerce contient la commande mais pas l’ERP ou le système logistique, examinez l’éligibilité, la détection, le traitement, l’acceptation à destination et la correspondance des identités avant toute réexécution.
Un écran de commandes WooCommerce lent ne constitue pas un unique problème de performance. Distinguez liste, recherche, ouverture, enregistrement et opérations groupées, puis attribuez la latence à la base, à PHP, aux extensions, aux API distantes ou au navigateur.
Lorsqu’un webhook WooCommerce semble se déclencher deux fois, établissez d’abord ce qui s’est réellement répété. Protégez ensuite l’opération métier en aval par une idempotence atomique, un état durable et un rapprochement.
Lorsque les actions planifiées WooCommerce restent en attente, en retard ou en échec, le nombre de tâches ne constitue pas un diagnostic. Mesurez l’ancienneté, le débit, le rythme d’arrivée et la concentration des échecs, puis reprenez délibérément les opérations métier concernées.
Lorsqu’une base WooCommerce continue de grossir, la réduire n’est pas la première tâche. Comparez les variations des tables, identifiez le processus producteur, vérifiez la conservation et démontrez que le rythme de croissance revient à la normale.
Quand le tunnel de commande WooCommerce fonctionne pour certains clients et échoue pour d’autres, utilisez les tentatives réussies comme témoins. Comparez sessions, requêtes, journaux et états de commande pour repérer le premier point de divergence.
Lorsqu’une passerelle signale une transaction réussie alors que WooCommerce ne dispose d’aucune commande correspondante exploitable ou la considère encore comme impayée, le problème relève du rapprochement des transactions. Voici comment reconstituer le parcours de l’échec sans risque.