Une boutique transmet une commande à un outil de gestion. Le système reçoit la notification, mais la connexion se coupe avant qu’il confirme sa réception. La même commande peut ensuite faire l’objet d’une nouvelle notification, lors d’une mise à jour ou d’une relance maîtrisée de l’intégration. Ne supposez pas qu’un échec de livraison entraîne automatiquement une nouvelle tentative. Sans contrôle des doublons, une intégration risque de créer deux documents pour une seule commande. Concevoir le traitement compte autant que configurer l’adresse destinataire.
Définir l’événement utile
Un webhook WooCommerce envoie une notification vers une URL lors d’un événement configuré. Le sujet, l’adresse de livraison, l’état et le secret font partie des éléments à examiner dans la configuration. La documentation officielle décrit également les journaux disponibles pour comprendre les envois.
Choisissez l’événement selon le besoin métier. La création d’une commande ne signifie pas toujours que son règlement est confirmé. Une intégration de préparation de colis doit donc préciser à quel état elle autorise l’expédition. Écrivez cette condition avant de choisir le sujet de notification.
Protéger et reconnaître la réception
Le destinataire doit vérifier l’authenticité des notifications selon le mécanisme documenté, notamment la signature associée au secret. Ne publiez pas ce secret dans une page ou dans un ticket. Limitez aussi les permissions de l’intégration à ce dont elle a besoin et prévoyez son remplacement si un accès est compromis.
Conservez une référence au traitement effectué. Selon l’opération, cette référence peut associer l’événement reçu, la commande et l’action métier. La conception doit distinguer un doublon du même traitement et une véritable mise à jour ultérieure. Utiliser seulement le numéro de commande pour refuser tout nouvel événement empêcherait de traiter les évolutions nécessaires.
Tester les interruptions et les doublons
Dans un environnement d’essai, envoyez deux fois une notification de test et vérifiez qu’elle ne crée pas deux opérations identiques. Simulez également un refus, un délai de réponse et une donnée incomplète. Le résultat attendu doit être écrit pour chaque cas : mise en attente, refus explicite ou intervention humaine.
Exemple fictif : un outil crée une étiquette, puis échoue pendant l’enregistrement de sa référence. Au prochain essai, il doit retrouver l’étiquette existante ou appliquer une procédure maîtrisée. Relancer aveuglément l’ensemble du travail peut engager un deuxième coût ou produire un colis supplémentaire.
Rapprocher la boutique et le destinataire
Un code de réponse favorable ne prouve pas que toutes les opérations ultérieures sont terminées. Comparez les commandes attendues avec les références créées dans le système externe. Les journaux doivent permettre de retrouver une notification sans stocker inutilement des informations personnelles.
Le suivi des actions planifiées WooCommerce complète cette vérification lorsque l’intégration repose sur une file de tâches. Notre guide sur la surveillance des parcours WordPress propose de partir des résultats attendus plutôt que de la seule disponibilité de la page d’accueil.
Prévoir l’exploitation quotidienne
Désignez la personne qui traite les notifications en échec et le délai au-delà duquel un contrôle manuel commence. Documentez les conditions d’une relance et les effets qu’elle peut déclencher. En cas de changement de stockage, les tests HPOS doivent inclure ce connecteur.
Pour délimiter une intervention, WPASSIST présente ses interventions WordPress. Fournissez le sujet du webhook, un exemple anonymisé, les heures concernées et la différence entre la boutique et l’outil destinataire. Ces éléments permettent de rechercher la cause sans partager les secrets de l’intégration.
Sources et vérification
Sources primaires consultées le 30 septembre 2026.
