Commandes WooCommerce absentes de votre ERP ou système logistique : les retrouver et les récupérer

La réponse courte

Pour chaque commande WooCommerce attendue dans un autre système, établissez cette chaîne :

Commande WooCommerce
→ éligible à la synchronisation
→ détectée par l’intégration
→ acceptée durablement pour traitement
→ transmise vers la destination
→ acceptée par la destination
→ ID externe enregistré
→ état métier rapproché

La première frontière non démontrée marque le début de l’investigation.

Ne classez pas une commande comme manquante uniquement parce qu’un tableau de bord ne l’affiche pas.

Ne la classez pas comme synchronisée uniquement parce qu’une requête HTTP a réussi.

"La commande existe dans WooCommerce" n’est que le premier fait

WooCommerce peut exposer les commandes via son API REST actuelle et notifier les systèmes externes par webhooks.

La collection /wp-json/wc/v3/orders prend en charge la pagination et les filtres, dont les fenêtres de création et de modification.

Cela établit ce que WooCommerce peut fournir.

Une intégration doit encore décider :

• quelles commandes sont éligibles
• quand elles le deviennent
• comment elles sont détectées
• comment collecter des résultats complets
• quelle représentation attend la destination
• comment conserver les échecs
• comment relier les enregistrements de destination à la source
• comment retrouver ensuite les enregistrements manquants ou incertains

Cette logique se situe souvent en partie hors de WooCommerce.

Commencez par deux faits indépendants :

WooCommerce contient la commande 18452.

et :

L’enregistrement attendu à destination ne peut actuellement pas être confirmé.

Tout ce qui relie ces faits reste à démontrer.

Établir un registre de rapprochement des commandes

Pour les incidents de commandes manquantes, créez un registre temporaire de rapprochement.

Il devient le dossier central du diagnostic.

Pour chaque commande suspecte, renseignez la chaîne dans la mesure où les éléments disponibles le permettent.

Les catégories utiles comprennent :

• jamais éligible
• éligible mais jamais sélectionnée
• sélectionnée mais jamais acceptée durablement
• acceptée localement mais traitement échoué
• rejetée par la destination
• acceptée à destination mais accusé perdu
• enregistrement à destination présent mais correspondance perdue
• retardée
• entièrement synchronisée
• toujours inconnue

C’est bien plus utile qu’un état unique nommé "échec de synchronisation".

Frontière d’échec 1 : la commande n’a jamais été éligible

La logique d’éligibilité est une source fréquente de "commandes manquantes".

Une intégration peut volontairement ne synchroniser que les commandes ayant :

• certains statuts
• certains moyens de paiement
• certains produits
• certains pays
• certains modes d’expédition
• certains types de clients
• les métadonnées requises
• une valeur dans une plage approuvée
• un indicateur métier spécifique

Un connecteur peut par exemple exporter une commande uniquement lorsqu’elle passe à En cours ou Terminée.

Les statuts WooCommerce ont des significations métier distinctes. Une commande payée de produits physiques passe couramment à En cours, tandis que En attente peut signifier que le paiement reste à confirmer. Les boutiques peuvent aussi ajouter des statuts spécifiques.

La question essentielle est :

Au moment où l’intégration a évalué cette commande, satisfaisait-elle la règle de synchronisation configurée ?

Ne comparez pas uniquement le statut actuel de la commande.

Elle peut être devenue éligible plus tard.

Le moment fait partie des éléments à examiner.

L’éligibilité doit avoir une raison vérifiable

Une intégration fiable doit permettre d’expliquer les exclusions.

Plutôt que d’ignorer silencieusement une commande, le système doit permettre d’établir par exemple :

La commande 18452 n’a pas été exportée car le statut on-hold est exclu.

ou que :

La commande 18452 a été différée car la correspondance du client externe était incomplète.

Un défaut apparent de synchronisation devient ainsi une règle métier explicite.

La documentation actuelle de dépannage MyWorks fournit un exemple concret. Lorsque les commandes WooCommerce ne se synchronisent pas automatiquement avec QuickBooks Online, elle invite à vérifier les réglages de synchronisation automatique, les statuts sélectionnés, les correspondances de moyens de paiement et le journal de synchronisation.

Ces détails sont propres au connecteur.

L’exigence d’ingénierie générale est :

Si une commande a été exclue, vous devez pouvoir expliquer pourquoi.

Frontière d’échec 2 : la commande était éligible mais n’a jamais été détectée

Certaines intégrations sont pilotées par webhooks.

D’autres interrogent WooCommerce périodiquement.

Certaines utilisent les deux.

Leurs modes de défaillance diffèrent.

Détection par webhooks

Les webhooks WooCommerce peuvent notifier un endpoint lors d’événements de commande.

Un flux peut ne pas démarrer si un webhook est :

• en pause
• désactivé après des échecs répétés de livraison
• dirigé vers le mauvais endpoint
• rejeté par l’authentification ou les règles du pare-feu
• livré à un récepteur qui échoue avant d’enregistrer durablement l’événement

WooCommerce expose des éléments de livraison des webhooks, notamment les journaux de requête et de réponse.

Cet historique ne doit pas servir d’archive forensique permanente. La documentation de l’API webhook WooCommerce ne conserve qu’un nombre limité de journaux de livraison récents.

Pour une intégration importante, conservez vos propres éléments de corrélation durables pour les événements et opérations métier acceptés.

Détection par interrogation périodique

Une intégration par polling demande généralement à WooCommerce les commandes créées ou modifiées dans une fenêtre contrôlée.

L’API Commandes actuelle de WooCommerce prend notamment en charge les filtres :

• after
• before
• modified_after
• modified_before

avec une interprétation explicite des dates et de GMT.

Ce sont des primitives utiles de synchronisation.

Elles ne constituent pas un algorithme complet de synchronisation.

L’intégration doit encore définir explicitement :

• l’ordre de tri
• la signification du point de reprise
• la complétude des pages
• le chevauchement
• la récupération après échec
• les mises à jour concurrentes

Une sémantique de point de reprise fragile peut créer des lacunes entre fenêtres

Supposons qu’une exécution enregistre un point de reprise vers 14:00 et que la suivante ne demande que les enregistrements strictement postérieurs.

Demandez alors ce que garantit le système lorsque :

• les horloges de la source et de l’intégration diffèrent
• une ancienne commande est modifiée pendant un lot en cours
• un point de reprise avance avant l’acceptation sûre de chaque élément
• des tentatives sont relancées après l’avancement du curseur source
• le tri de la requête et le champ du point de reprise ne correspondent pas

La conception sûre dépend de l’intégration.

Un schéma courant de fiabilité combine une fenêtre de chevauchement contrôlée, un traitement répétable sans effet indésirable et un rapprochement.

Le chevauchement peut produire des candidats répétés.

C’est maîtrisable si les traitements en double sont contrôlés.

Une lacune silencieuse est bien plus difficile à détecter sans processus de rapprochement.

La pagination participe à la correction de la synchronisation

Les endpoints de collection WooCommerce sont paginés.

L’API REST expose les contrôles de pagination et des en-têtes de réponse comme le nombre total de ressources et de pages.

Une intégration doit traiter l’intégralité du jeu de résultats visé.

Ne supposez pas que :

première réponse API réussie = toutes les commandes éligibles traitées

Si 250 commandes sont éligibles et qu’un client ne récupère que la première page, les autres peuvent sembler "manquantes" alors que WooCommerce a répondu correctement.

Les jeux de données dynamiques nécessitent aussi un tri et des points de reprise délibérément définis.

Des enregistrements nouveaux ou modifiés peuvent apparaître pendant une longue synchronisation.

Ce n’est pas en soi un défaut de WooCommerce.

Cela fait partie de la conception de l’intégration.

Frontière d’échec 3 : la détection a réussi, pas le traitement durable

Une intégration peut lire une commande avec succès et la perdre avant le début du véritable traitement.

Une séquence fragile est :

read WooCommerce order
advance checkpoint
attempt processing later
process crashes

Le cycle suivant peut commencer au-delà de la position source de cette commande.

Une frontière de responsabilité plus sûre est :

discover
durably record or enqueue
advance checkpoint

L’implémentation peut varier, mais le principe reste :

Ne pas avancer le curseur source au-delà du travail que l’intégration n’a pas accepté de manière sûre.

Si Action Scheduler ou une autre file intervient, vérifiez que la tâche attendue a réellement été créée.

Si la tâche existe mais est retardée ou en échec, cela relève du problème distinct de santé des files traité dans diagnostic des retards d’actions planifiées WooCommerce.

Frontière d’échec 4 : traitement démarré, mais commande rejetée par la validation

Le connecteur peut accepter l’enregistrement WooCommerce mais le rejeter avant tout appel à l’API de destination.

Les raisons courantes comprennent :

• produit ou SKU sans correspondance
• correspondance client manquante
• pays ou région non pris en charge
• structure d’adresse invalide
• données fiscales requises absentes
• devise non prise en charge
• correspondance du moyen de paiement absente
• champ spécifique requis absent
• relation incohérente entre produit et variation

La documentation actuelle de l’intégration ERPNext hébergée par WooCommerce illustre les mêmes enjeux opérationnels : correspondances de statuts et de paiements, synchronisation planifiée, journaux et resynchronisation manuelle influencent l’arrivée correcte d’une commande dans l’ERP en aval.

Les détails d’implémentation varient selon le connecteur.

Le principe général reste :

Une commande WooCommerce valide n’est pas automatiquement un document valide pour la destination.

L’intégration doit exposer l’exigence de destination qui a empêché la progression.

Corriger la correspondance, pas l’historique commercial

Supposons que l’ERP rejette une commande faute de correspondance SKU.

Vous corrigez la correspondance.

Cela ne signifie pas automatiquement qu’il faille modifier la commande WooCommerce d’origine.

La commande WooCommerce peut déjà représenter correctement la transaction commerciale.

Le défaut peut se situer dans :

• la table de correspondance
• la logique de transformation
• les données de référence de la destination
• la procédure de réexécution

Les données historiques de commande ne doivent pas être modifiées simplement pour satisfaire une intégration, à moins de comprendre le sens métier de ce changement.

Corrigez la frontière responsable.

Récupérez ensuite la commande par ce chemin corrigé.

Frontière d’échec 5 : la destination rejette la requête

Dès que l’intégration appelle le système externe, classez la réponse.

Échec d’authentification

Exemples :

• jeton expiré
• clé API révoquée
• une signature invalide
• périmètre d’autorisations modifié

La destination n’a pas nécessairement accepté l’opération métier.

Échec de validation

La destination a compris la requête mais en a rejeté le contenu.

Exemples :

• SKU inconnu
• fiche client absente
• compte de taxe invalide
• entrepôt indisponible
• champ mal formé
• transition d’état invalide

Limitation de débit

La destination refuse temporairement du travail supplémentaire.

Une nouvelle tentative peut convenir si l’opération est répétable sans effet indésirable.

Échec serveur

Un statut distant 5xx indique une défaillance côté serveur ou une dépendance indisponible.

Là encore, la politique de nouvelle tentative compte.

Définissez :

• les échecs pouvant être réessayés
• le délai avant une nouvelle tentative
• le nombre maximal de tentatives
• l’âge maximal
• l’état d’échec terminal
• la procédure de rapprochement

Ne transformez pas chaque erreur en boucle de tentatives infinie.

Un transport réussi n’est pas toujours une acceptation métier

Cette distinction compte lorsque du middleware se trouve entre WooCommerce et la destination finale.

L’intégration envoie une commande au middleware.

Le middleware renvoie :

202 Accepted

ou que :

200 OK

Cela peut signifier :

J’ai accepté votre requête pour traitement ultérieur.

Cela ne signifie pas nécessairement :

La commande de vente ERP-78291 existe maintenant dans l’ERP.

Une réponse de transport réussie peut aussi contenir un état différé ou un échec métier.

Pour la synchronisation, distinguez :

l’acceptation du transport

de :

l’acceptation métier à destination

L’exploitation a en définitive besoin de preuves telles que :

• ID de commande à destination
• document de vente confirmé
• enregistrement d’exécution logistique
• ID de transaction comptable
• état accepté à destination

Frontière d’échec 6 : réussite à destination, mais accusé perdu

C’est ici que la réexécution aveugle devient dangereuse.

Considérez cette séquence :

1. La commande WooCommerce 18452 est envoyée.
2. L’ERP crée ERP-78291.
3. La réponse est perdue ou l’intégration plante avant de l’enregistrer.
4. L’état local indique toujours que la commande n’est pas synchronisée.
5. Quelqu’un relance la création.
6. Un second enregistrement ERP peut être créé.

L’incident visible semblait être :

commande absente de l’ERP

mais l’opération externe avait déjà réussi.

L’échec réel était :

la réussite ne pouvait pas être confirmée localement.

Avant de réexécuter une opération incertaine, recherchez-la à destination à l’aide d’identifiants stables.

Les éléments possibles comprennent :

• identifiant de commande WooCommerce
• champ de référence externe
• numéro de commande
• clé d’opération de l’intégration
• client, montant et horodatage comme éléments complémentaires

Évitez le rapprochement approximatif comme mécanisme principal d’identité lorsqu’un identifiant stable peut être prévu.

C’est le même problème d’effets de bord en double que celui abordé dans éviter le traitement en double des webhooks WooCommerce.

Chaque commande synchronisée nécessite une identité stable entre systèmes

L’intégration doit au minimum pouvoir répondre :

Quel enregistrement à destination correspond à la commande WooCommerce 18452 ?

La réponse ne doit pas exiger une comparaison manuelle des noms des clients.

Conservez une correspondance durable telle que :

WooCommerce order ID → destination record ID

Par exemple :

18452 → ERP-78291

Selon les responsabilités des systèmes, la correspondance peut résider dans :

• les métadonnées WooCommerce
• une table dédiée à l’intégration
• le middleware
• la destination
• plusieurs systèmes observables si nécessaire

La fiabilité des correspondances, des nouvelles tentatives et du rapprochement relève de l’ingénierie des API et intégrations WooCommerce et non de détails accessoires du connecteur.

L’ID de commande et le numéro affiché sont des identifiants distincts

WooCommerce expose un id de ressource interne et un numéro de commande distinct.

Les extensions de numérotation personnalisée peuvent modifier le numéro de commande visible.

Une intégration ne doit pas supposer implicitement :

displayed order number = immutable WooCommerce resource ID

Définissez l’identifiant machine utilisé pour la correspondance source.

Si la destination crée son propre ID immuable, conservez-le également séparément.

Les libellés lisibles aident les équipes opérationnelles.

Une identité machine stable rend la récupération fiable.

Frontière d’échec 7 : l’enregistrement existe en aval mais l’équipe ne le voit pas

Parfois, la synchronisation a réussi et la vue opérationnelle est trompeuse.

L’enregistrement en aval peut être :

• dans une file de rejet ou de révision
• dans un état brouillon ou import
• affecté à un autre entrepôt
• exclu par les filtres de la vue actuelle
• sous un autre statut
• associé à une autre fiche client
• masqué par les autorisations
• en attente d’un traitement par lots en aval

Avant de déclarer une commande absente, élargissez la recherche à destination à l’aide d’identifiants stables.

"Le tableau de bord de l’entrepôt ne l’affiche pas" ne signifie pas :

l’API ou la base de destination ne contient aucun enregistrement correspondant.

La frontière manquante reste à prouver.

Frontière d’échec 8 : la file est retardée, pas défaillante

Supposons que les commandes apparaissent habituellement dans l’ERP en une minute.

Aujourd’hui, elles en mettent vingt.

Cela ne signifie pas nécessairement que des commandes sont perdues.

La chaîne de synchronisation peut avoir accumulé du retard.

Si des traitements en arrière-plan interviennent, examinez :

• le travail en attente le plus ancien
• le débit
• le taux d’arrivée
• les échecs répétés
• la latence externe

Ne relancez pas manuellement une commande tant que sa tâche initiale attend, sauf si la protection contre les doublons est établie.

La tentative initiale et la tentative manuelle peuvent toutes deux s’exécuter plus tard.

Définir un modèle d’état de complétude des commandes

Chaque commande attendue dans le flux externe doit correspondre à un état explicite.

Par exemple :

Non éligible

Les règles métier excluent son exportation.

Éligible

La commande satisfait la règle d’exportation mais n’a pas encore été sélectionnée.

Acceptée localement

L’intégration a accepté durablement la responsabilité du traitement.

En transmission

Le traitement vers le système externe est en cours.

Rejetée

Un problème connu de validation ou de dépendance a empêché l’acceptation.

Acceptée à l’extérieur

La destination confirme l’existence de l’enregistrement métier attendu.

Rapprochée

L’identité source, l’identité de destination et l’état métier attendu concordent.

Échec définitif

La récupération automatique est terminée et une intervention humaine est nécessaire.

Les noms peuvent varier.

L’essentiel est d’éliminer l’état indéfini :

peut-être synchronisée

Le rapprochement diffère d’une nouvelle tentative

Une nouvelle tentative dit :

Réessayer l’opération.

Le rapprochement dit :

Établir l’état réel des deux systèmes, puis décider quelle opération reste éventuellement nécessaire.

Supposons que WooCommerce contienne la commande 18452.

L’état local de l’intégration indique un échec.

L’ERP contient ERP-78291.

Créer une autre commande ERP serait incorrect.

Le rapprochement dit :

L’enregistrement existe déjà à destination. Rétablir la correspondance et marquer l’opération comme terminée.

Considérez maintenant la commande 18453.

WooCommerce la contient.

Aucun enregistrement durable d’acceptation par l’intégration n’existe.

L’ERP ne contient aucun enregistrement correspondant.

Le rapprochement dit :

L’opération requise à destination manque réellement. Mettre sa création en file de manière sûre.

Des preuves différentes conduisent à des actions de récupération différentes.

Produire un rapport de rapprochement, pas seulement un bouton de renvoi

Pour les intégrations importantes en exploitation, produisez un rapport répondant à :

La synchronisation devient ainsi un processus métier auditable.

Une question d’intégration plus utile est :

Quelles commandes WooCommerce devraient exister en aval mais n’y sont actuellement pas ?

C’est plus utile que de demander uniquement si le cron d’hier s’est exécuté.

Définir l’autorité avant le rapprochement

Avant de comparer les systèmes, définissez lequel fait autorité pour chaque information à chaque étape.

Pour la création sortante de commandes, WooCommerce peut faire autorité pour :

• l’identité de la commande issue du checkout
• les articles achetés
• les adresses saisies par le client
• l’état de commande issu du paiement

L’ERP peut ensuite faire autorité pour :

• l’affectation d’entrepôt
• le document d’exécution logistique
• la facturation
• l’état d’expédition

Les responsabilités varient.

Un processus de rapprochement ne doit pas écraser aveuglément un système avec l’autre parce que deux valeurs diffèrent.

Demandez d’abord :

Quel système fait autorité pour ce champ ou cet état à cette étape du flux ?

Cela devient encore plus important pour la synchronisation des stocks, expéditions et remboursements.

Récupérer une commande manquante seulement après avoir prouvé son absence

Avant de réexécuter une création de commande, vérifiez :

1. La commande WooCommerce est valide pour la synchronisation.
2. Aucune correspondance confirmée à destination n’est déjà enregistrée.
3. La recherche à destination ne trouve aucun enregistrement correspondant existant.
4. Le traitement initial n’est plus en attente.
5. Aucun autre worker ne détient actuellement l’opération.
6. Les correspondances et la configuration requises passent désormais la validation.
7. Le chemin de réexécution est idempotent ou autrement protégé contre les doublons.
8. Le délai métier rend toujours l’opération valable.

C’est seulement alors qu’il faut tenter une création manquante.

Cette démarche est volontairement plus prudente qu’un clic sur "Réessayer tous les échecs".

Une étude de cas publique DevFluxr documente déjà étude de cas d’intégration API WooCommerce des schémas fondés sur des identifiants stables, des files, des tentatives bornées et le rapprochement. Ces mêmes contrôles comptent lors de la récupération.

Récupérer par lots contrôlés

Si trois commandes manquent, la récupération est généralement simple.

Si 30 000 sont incertaines, la récupération devient une charge de production.

Ne renvoyez pas immédiatement l’ensemble de la plage.

Procédez par étapes :

sample → verify destination → small batch → observe → increase carefully

Surveillez :

• les limites de débit de la destination
• la croissance de la file
• la latence API
• les doublons
• l’utilisation des ressources locales
• le volume opérationnel en aval

Une récupération qui submerge l’ERP n’est pas une récupération réussie.

Les lots partiels nécessitent des preuves par élément

Supposons qu’un lot doive envoyer 500 commandes.

Les 327 premières réussissent.

Puis la destination commence à échouer.

Si le seul état enregistré est :

lot en échec

la récupération est ambiguë.

Aucune n’a-t-elle réussi ?

327 ont-elles réussi ?

Le dernier accusé a-t-il été perdu ?

Un traitement par lots fiable doit conserver les résultats par élément ou fournir un rapprochement capable de les reconstituer.

La récupération doit cibler :

le sous-ensemble manquant

plutôt que réexécuter tout le lot, sauf si l’opération entière est démontrée répétable sans effet indésirable.

Les webhooks et le rapprochement résolvent des problèmes distincts

Les webhooks sont utiles pour les notifications à faible latence.

Pour une intégration critique pour le chiffre d’affaires, ils ne doivent pas être le seul contrôle protégeant la complétude des commandes.

Un schéma courant de fiabilité est :

Webhook → notification rapide d’événement

plus :

Rapprochement périodique → détection des commandes manquantes ou incertaines

Une tâche de rapprochement peut demander :

Quelles commandes WooCommerce sont devenues éligibles dans cette fenêtre contrôlée, et lesquelles n’ont pas de correspondance confirmée à destination ?

Cela crée un chemin de récupération lorsque :

• la livraison du webhook a échoué
• un endpoint était temporairement indisponible
• le traitement de la file a échoué
• un déploiement a interrompu le traitement
• l’état de correspondance a été perdu

Les webhooks améliorent la réactivité.

Le rapprochement améliore la capacité de récupération.

Le rapprochement ne doit pas devenir une autre source de charge en double

Un rapprochement mal conçu peut lui-même générer du travail répété.

Évitez de relire sans cesse l’historique de la boutique et de renvoyer tout ce qui semble incomplet.

Privilégiez :

• des fenêtres de temps bornées
• des identifiants stables
• des états explicites
• des points de reprise incrémentaux
• un chevauchement contrôlé si pertinent
• des décisions répétables sans effet indésirable
• assez d’éléments pour expliquer chaque résultat

Les journaux doivent répondre aux questions métier

Les codes de statut HTTP sont utiles.

Ils ne suffisent pas aux opérations.

Pour chaque commande, il faut idéalement pouvoir répondre :

• Était-elle éligible ?
• A-t-elle été détectée ?
• A-t-elle été acceptée localement ?
• Une requête a-t-elle été envoyée à destination ?
• Qu’a renvoyé la destination ?
• Quel ID externe a été attribué ?
• Quel est l’état actuel de récupération ?

C’est l’observabilité opérationnelle.

Elle permet au support, à la logistique et à l’ingénierie de discuter du même incident à partir d’une chaîne de preuves commune.

Ne pas marquer la synchronisation terminée trop tôt

"Mise en file réussie" ne signifie pas que la destination a accepté la commande.

"Requête HTTP envoyée avec succès" ne signifie pas que l’ERP a créé le document attendu.

Utilisez des noms d’état décrivant ce qui s’est réellement passé.

Par exemple :

queued → delivery_attempted → destination_accepted → reconciled

est plus informatif qu’un simple booléen :

synced = 1

Un booléen élimine les éléments intermédiaires nécessaires lorsqu’un flux échoue en cours de route.

Éviter les contrôles de santé unilatéraux

Une intégration peut sembler saine depuis WooCommerce parce que :

• les appels API reçoivent des réponses de transport réussies
• les files sont vides
• aucune exception locale n’est visible

Pendant ce temps, la destination peut rejeter une partie des commandes vers une file de validation.

L’inverse peut également se produire.

Un contrôle pertinent de complétude compare :

les enregistrements source attendus

aux :

enregistrements confirmés à destination

C’est pourquoi le rapprochement est plus robuste que la surveillance d’une seule application.

Vérification après récupération

Ne clôturez pas l’incident dès que la commande manquante apparaît en aval.

Pour chaque commande récupérée, établissez que :

• l’enregistrement existe une seule fois pour l’opération métier visée
• la correspondance d’identité entre systèmes est enregistrée
• le bon client est associé
• les articles et quantités concordent
• les totaux et la devise sont corrects
• les informations d’expédition sont correctes
• le statut attendu à destination est correct
• la logistique et la comptabilité en aval continuent normalement
• aucune tâche en double ne reste en attente
• les nouvelles commandes se synchronisent sans intervention manuelle

Observez ensuite les commandes suivantes.

Les enregistrements d’hier peuvent être réparés manuellement alors que les commandes de demain restent exposées au même défaut.

La récupération et la prévention de récidive sont deux livrables distincts

Un incident entièrement traité a deux résultats.

Récupération de l’incident

Rétablir les enregistrements métier précisément manquants ou incertains.

Correction de fiabilité

Supprimer la condition qui a permis leur disparition silencieuse.

Exemple :

Récupération : créer trois commandes ERP dont l’absence réelle est prouvée.

Correction : corriger la règle d’éligibilité et ajouter un rapprochement pour rendre visibles les futures commandes exclues ou non traitées.

Autre exemple :

Récupération : rétablir les correspondances vers des enregistrements ERP déjà existants.

Correction : enregistrer l’identité de destination de manière sûre avant d’avancer l’état d’achèvement de l’intégration.

Les deux comptent.

Une séquence de diagnostic pratique

1. Définir ce que signifie "manquante"

   Relevez :

   • commande source
   • destination attendue
   • délai attendu
   • document ou état attendu à destination

2. Sélectionner des exemples représentatifs

   Utilisez :

   • une commande manquante
   • une commande réussie de la même période
   • un autre échec si disponible

   Un cas témoin réussi aide à situer la première divergence.

3. Vérifier l’éligibilité

   Comparez :

   • statut
   • état du paiement
   • exigences produit/client
   • prérequis de correspondance
   • filtres métier

4. Vérifier la détection

   La commande a-t-elle été :

   • incluse dans l’activité des webhooks ?
   • renvoyée dans la fenêtre d’interrogation prévue ?
   • incluse dans les pages de résultats API attendues ?
   • enregistrée par l’intégration ?

5. Vérifier l’acceptation durable

   L’intégration a-t-elle accepté de manière sûre la responsabilité de la commande avant d’avancer son point de reprise ?

6. Vérifier la file ou le traitement en arrière-plan

   La tâche attendue existait-elle ?

   S’est-elle exécutée ?

   A-t-elle échoué ?

7. Vérifier la livraison à destination

   Relevez :

   • requête
   • réponse
   • erreur de transport
   • résultat de validation métier

8. Rechercher indépendamment à destination

   Ne vous fiez pas uniquement à l’état local de synchronisation.

   Recherchez à l’aide de l’identité stable entre systèmes.

9. Classer l’échec

   Choisissez l’état le mieux étayé :

   • exclue
   • omise
   • retardée
   • rejetée
   • acceptée mais sans correspondance
   • déjà synchronisée
   • inconnue

10. Récupérer uniquement l’opération nécessaire

    Ne réexécutez pas un traitement déjà confirmé en aval.

11. Vérifier le résultat métier attendu

    Confirmez qu’une commande source visée produit le résultat attendu à destination sans doublon accidentel.

12. Ajouter le rapprochement

    Rendez détectables les futures lacunes silencieuses.

Le critère de réussite utile

Une intégration fiable ne se résume pas à :

l’endpoint webhook est en ligne.

Ni à :

le cron s’est exécuté.

Ni même à :

l’API a renvoyé 200.

Le critère utile est :

Chaque commande WooCommerce devant entrer dans le flux externe peut être justifiée : elle possède soit un enregistrement confirmé à destination, soit un motif explicite de non-éligibilité, soit un état d’échec visible et récupérable.

C’est la complétude des commandes.

En deçà, l’activité dépend du silence du système.

Prévenir les incidents de commandes manquantes

Pour les intégrations importantes entre WooCommerce et un ERP ou système logistique, définissez explicitement ces contrats.

Éligibilité

Quelles commandes entrent dans le flux externe, et quand ?

Identité stable

Comment une commande WooCommerce correspond-elle à l’enregistrement externe ?

Détection

Webhook, polling ou les deux ?

Points de reprise

Quand peut-on avancer sans risque la progression source ?

Pagination et fenêtres

Comment collecter des résultats complets sans lacunes ?

Validation

Comment vérifier les exigences de la destination ?

État du traitement

L’exploitation peut-elle distinguer mise en file, tentative, acceptation et rapprochement ?

Nouvelle tentative

Quels échecs peut-on réessayer sans risque ?

Idempotence

Comment éviter les enregistrements externes en double ?

Rapprochement

Comment détecter ensuite les enregistrements manquants ou incertains ?

Observabilité

Peut-on suivre une commande WooCommerce de la source à la destination ?

Ces contrats forment le modèle de récupération d’une intégration critique pour le chiffre d’affaires.

Quand faire appel à une expertise spécialisée

Une investigation spécialisée devient pertinente lorsque :

• des commandes WooCommerce payées manquent dans l’ERP ou la plateforme logistique
• seules certaines commandes ne se synchronisent pas
• les journaux du connecteur indiquent un succès mais l’équipe ne trouve pas l’enregistrement
• un renvoi manuel risque de créer des doublons
• les règles de statut ou des statuts spécifiques affectent l’éligibilité
• la pagination API ou les fenêtres de dates interviennent
• la synchronisation utilise des tâches de fond pouvant être retardées
• la validation à destination échoue pour certains produits ou clients
• la livraison des webhooks et l’état du connecteur se contredisent
• les ID externes ne sont pas conservés de manière cohérente
• un lot n’a réussi qu’en partie
• les équipes comparent les systèmes manuellement pour retrouver les commandes manquantes
• des tentatives précédentes ont récupéré certaines commandes sans que personne puisse expliquer la disparition des autres

L’objectif n’est pas de renvoyer des commandes jusqu’à égaliser les décomptes.

Il consiste à :

Reconstituez la complétude entre les deux systèmes, identifiez la première frontière non prouvée, récupérez uniquement les opérations réellement absentes, puis rendez les futures lacunes visibles et rapprochables.