Reconstituer la chronologie d’une commande

Le problème concret

Le client affirme avoir payé, WooCommerce affiche « en attente » et le prestataire montre une opération. L’e-mail peut avoir été envoyé sans que l’accès soit accordé, ou l’inverse. Chaque système utilise ses propres événements et son propre fuseau horaire.

Modifier manuellement le statut sans chronologie peut délivrer un produit non payé ou déclencher deux fois les mêmes actions. Le diagnostic doit relier une commande, une transaction, un webhook et les conséquences produites.

Ce qu’il faut comprendre

Une chronologie fiable repose sur des identifiants et des preuves, pas sur l’ordre des e-mails. Le navigateur initie, le prestataire autorise ou capture, le webhook informe la boutique, WooCommerce change de statut et les extensions réagissent. Une redirection du navigateur réussie n’est pas une preuve suffisante du paiement.

Avant d’intervenir

Ne commencez pas par appliquer une astuce. Reproduisez la situation, notez la date, l’URL, le compte utilisé et les versions des composants concernés. Travaillez sur une copie lorsque la manipulation peut toucher l’affichage, les données, les commandes ou les accès. Vérifiez qu’une sauvegarde récente existe et que vous savez quelle partie restaurer. Prenez une capture de l’état initial et copiez les valeurs que vous allez modifier. Une intervention reste ainsi comparable et annulable.

Diagnostic guidé

Avant de modifier le site, rassemblez des faits comparables. Procédez dans cet ordre :

• Relevez numéro de commande, date UTC et locale, client, montant, devise et moyen de paiement.
• Dans les notes de commande, copiez les changements de statut et messages du moyen de paiement.
• Chez le prestataire, retrouvez l’identifiant exact et distinguez créé, autorisé, capturé, échoué ou remboursé.
• Consultez les webhooks et journaux en supprimant clés, données bancaires et informations personnelles inutiles.

Procédure détaillée

1. Créer la ligne du temps. Placez chaque événement avec heure, système, identifiant, état et preuve. Convertissez les heures dans un même fuseau.
2. Relier les identifiants. Vérifiez que la transaction du prestataire porte bien la référence de la commande et le même montant. Ne concluez pas à partir du seul nom du client.
3. Identifier la rupture. Repérez le premier événement attendu absent : capture, webhook, traitement WooCommerce, tâche ou action de délivrance.
4. Tester sans modifier le passé. Sur préproduction ou avec une commande test, reproduisez le scénario. Si un webhook doit être rejoué, assurez-vous que le traitement est idempotent.
5. Corriger et documenter. Réparez la configuration, le point de terminaison ou le traitement, puis vérifiez la commande test entière avant toute régularisation manuelle.

Cas pratique

Le paiement est capturé à 14 h 02, mais la commande reste en attente. Le webhook montre une réponse HTTP 401 après un changement de protection. La redirection client a néanmoins affiché la confirmation. L’autorisation sécurisée du endpoint rétablit le webhook. Une commande test prouve le changement automatique avant que la commande réelle soit régularisée.

Interpréter les résultats

• Si la capture est confirmée et unique, la commande peut être régularisée après traitement de la cause.
• Si seule une autorisation existe, vérifiez la logique de capture avant de délivrer.
• Si aucun identifiant ne relie l’opération à la commande, demandez une preuve supplémentaire au lieu de supposer.

Tu es un assistant de diagnostic WordPress. Tu ne dois inventer aucun fait, réglage, résultat ou version.

OBJECTIF

Corrèle une commande WooCommerce, sa transaction, ses webhooks et son accès distant sans confondre les statuts.

CONTEXTE À UTILISER

– identifiant de commande : {{à compléter}}

– identifiant de transaction : {{à compléter}}

– événements et heures : {{à compléter}}

– notes WooCommerce : {{à compléter}}

– journaux du paiement : {{à compléter}}

– état du portail : {{à compléter}}

CONSIGNES

1. Commence par lister les informations manquantes qui empêchent une conclusion fiable.

2. Classe les hypothèses du test le moins risqué au plus risqué.

3. Pour chaque hypothèse, indique le contrôle, la preuve attendue et ce qui l’invaliderait.

4. Sépare clairement observation, hypothèse et recommandation.

5. Ajoute une sauvegarde préalable, une procédure de retour arrière et une vérification après intervention.

6. Si une action peut toucher la production, les commandes, les comptes ou les données, demande un test sur une copie.

FORMAT DE RÉPONSE ATTENDU

– chronologie dans un fuseau unique

– contradictions entre systèmes

– source de vérité

– action sûre et idempotente

Termine par : « Ce qui doit être validé par un humain avant toute action ».

Exercice à réaliser

Prenez une commande test réussie et reconstituez au moins six événements. Simulez ensuite un webhook refusé et identifiez précisément la rupture, sans changer le statut à la main.

Livrable : la fiche d’incident, la chronologie unifiée et la preuve du premier événement manquant.

Documenter la décision

Dans votre compte rendu, séparez l’observation, l’hypothèse, le test, le résultat et la décision. Indiquez aussi les hypothèses écartées : elles évitent de recommencer le même diagnostic. Joignez les mesures ou captures avant/après, mais retirez les données personnelles, clés, jetons et informations de paiement. Une autre personne doit pouvoir comprendre ce qui a été testé, reproduire le contrôle et exécuter le retour arrière sans dépendre de votre mémoire.

Critères de réussite

• Chaque état a une source.
• Commande et transaction sont reliées.
• La rupture est identifiée avant correction.
• Aucune donnée sensible ne figure dans le rapport.

Retour arrière

Ne modifiez pas la commande réelle pendant le diagnostic. Restaurez le réglage du endpoint si le test perturbe d’autres flux, puis vérifiez les webhooks en attente. Toute régularisation manuelle doit être notée dans la commande.

Erreurs fréquentes

Approfondissement : raisonner comme lors d’une intervention

La commande WooCommerce est une vue parmi plusieurs. Le prestataire de paiement, les notes de commande, les webhooks, les tâches planifiées et le portail peuvent avoir des états divergents. Construisez une chronologie avec identifiants et fuseau unique. Un même libellé comme « réussi » peut décrire une autorisation, une capture ou seulement l’acceptation technique d’une requête.

Matrice de tests et de preuves

Ne cherchez pas à confirmer immédiatement votre première intuition. Traitez chaque point de diagnostic comme une hypothèse concurrente. Pour chaque ligne, conservez une preuve datée et indiquez si elle confirme, affaiblit ou ne permet pas de départager l’hypothèse.

Scénario avancé

Le client reçoit un débit bancaire mais la commande reste en attente. La chronologie associe commande, intention de paiement et événement webhook. Le prestataire confirme la capture ; le webhook a expiré avant d’atteindre le site. Après vérification de l’idempotence, l’événement est rejoué une fois. La commande passe au bon état et un seul droit est créé. La cause réseau est documentée séparément.

Rejouez ensuite le scénario dans les mêmes conditions, puis dans une condition volontairement différente. Cette seconde passe vérifie que le résultat vient bien de la modification et non d’un cache, d’une session, d’un délai externe ou d’une coïncidence.

Contrôle de compréhension

Quelle information doit être obtenue avant toute modification ?

Les identifiants corrélables, les heures et la signification exacte de chaque statut.

Quel résultat invaliderait votre hypothèse principale ?

La preuve financière contredisant la chronologie ou un autre événement expliquant la transition.

Quelle preuve doit rester dans le compte rendu ?

La ligne du temps complète, la source de vérité choisie et l’effet de la correction.

Revue finale à froid

Revenez sur l’intervention après une nouvelle connexion et, si le sujet le permet, depuis un autre navigateur ou un autre compte. Relisez votre rapport sans vous fier à votre mémoire : le contexte, les valeurs initiales, l’action, la preuve, la décision et le retour arrière doivent être compréhensibles. Si un de ces éléments manque, la leçon n’est pas encore terminée, même si le symptôme semble avoir disparu.

↓Télécharger la fiche de travail (PDF)PDF↓Version éditable (Markdown)MD