Partir d’une soumission que les deux équipes peuvent retrouver
Le formulaire Elementor affiche son message de confirmation et une entrée apparaît dans WordPress. Le service destinataire ne montre pourtant aucun dossier correspondant. Relevez la page, le nom du formulaire, l’heure et l’identifiant de l’entrée locale lorsqu’il existe. Vérifiez aussi ce que signifie « aucun dossier » pour le destinataire. La demande peut avoir été reçue puis refusée par la validation, mise en attente ou classée dans un autre espace. Demandez à la personne qui connaît le service où vérifier ces états.
Le webhook est une action qui transmet des données à une adresse configurée. Le stockage local de la soumission et le traitement distant sont des étapes distinctes. Une confirmation dans le navigateur indique ce que le visiteur a reçu pendant sa soumission. Pour vérifier le trajet complet, il faut retrouver l’essai dans les observations du destinataire et dans le résultat métier attendu. Commencez avec une seule demande synthétique et un repère commun. Évitez de demander au visiteur de renvoyer ses données avant d’avoir vérifié si le premier envoi a déjà eu un effet.
Préparer un essai sur un circuit isolé
Utilisez une copie privée où vous pouvez modifier le formulaire et un destinataire de test qui appartient à l’équipe. Désactivez sur cette copie les envois de courriel, créations de dossier ou autres actions externes qui sortiraient du circuit prévu. Conservez la configuration d’origine dans un emplacement réservé. Une adresse de webhook peut inclure un secret. Masquez-la dans les captures et communiquez seulement le domaine ou un alias interne lorsque cela suffit. Évitez les collecteurs publics, car ils recevraient les champs du formulaire et pourraient exposer son contenu.
Choisissez une valeur de contrôle unique, par exemple un motif de test accompagné de l’heure. N’utilisez pas de données réelles de visiteurs. Vérifiez avec le responsable du destinataire quels champs peuvent contenir ce repère. Préparez l’état attendu, par exemple une réception dans le journal puis une fiche de test dans l’espace prévu. Notez le fuseau utilisé par chaque système. Deux heures différentes peuvent représenter la même soumission. Gardez une fenêtre d’observation suffisamment longue pour le délai habituel du service si son traitement est asynchrone.
Vérifier les actions du widget réellement utilisé
Ouvrez la page dans Elementor et sélectionnez le widget Formulaire. Dans Contenu, examinez Actions After Submit. Vérifiez que Webhook fait partie des actions du widget et ouvrez le groupe associé. Relevez la destination en masquant sa partie sensible. Comparez-la à la destination de test confirmée par son propriétaire. Si le formulaire est fourni par un modèle ou un popup, ouvrez le modèle qui est réellement rendu. Plusieurs formulaires peuvent partager un nom ou des champs voisins.
L’action Collect Submissions peut servir de repère local lorsqu’elle est activée. Dans l’administration Elementor, ouvrez Submissions et cherchez l’entrée correspondant au marqueur de l’essai. Si vous ne trouvez aucune entrée et que la collecte est désactivée, utilisez le journal du parcours de test ou activez la collecte sur la copie selon le besoin. Lorsque l’enregistrement local existe mais que Webhook manque dans les actions, ajoutez-le sur la copie et configurez la destination. Enregistrez puis rouvrez le document pour vérifier que l’action a été conservée. Faites un seul nouvel essai et comparez les deux systèmes.
Comparer l’adresse enregistrée à la destination actuelle
Vérifiez le protocole, le domaine, le chemin et l’environnement du récepteur. Un service peut avoir remplacé une URL à la suite d’une rotation de secret ou d’une duplication de scénario. Une adresse de production et une adresse d’essai peuvent différer d’un seul segment. Comparez les valeurs sans copier le secret dans le relevé. Lorsque vous avez plusieurs formulaires traduits, relevez quelle configuration est utilisée par la langue qui pose problème. Un réglage corrigé sur le modèle principal peut laisser une variante avec l’ancienne destination.
Si le destinataire a déplacé son adresse, renseignez l’URL HTTPS finale approuvée sur la copie et vérifiez les redirections qu’il applique. Un transfert après redirection peut être traité différemment selon le client et la réponse. Une page de connexion n’est pas un récepteur de webhook. Vérifiez le trajet par le journal du service ou par les observations autorisées de l’hébergeur. Lorsque l’URL figure dans un outil de configuration partagé, faites confirmer qui la maintient avant de modifier une copie qui serait écrasée. Conservez une valeur de retour approuvée si le changement doit être retiré.
Suivre la tentative sortante depuis l’installation WordPress
Soumettez le formulaire de la copie et notez l’heure et le marqueur. Dans le navigateur, observez la requête de soumission vers le site WordPress. Elle permet de vérifier que le formulaire a été envoyé au site. La demande sortante vers le service peut être effectuée par le serveur et ne figure alors pas comme une requête du navigateur. Demandez au mainteneur WordPress ou au responsable de l’hébergement de retrouver la tentative sortante dans les outils déjà autorisés. Le relevé doit contenir le domaine, l’heure et le résultat, avec les secrets et les champs masqués.
Si aucune tentative n’est observée, vérifiez l’action activée, le document servi et la présence d’une erreur avant le déclenchement. Si une tentative apparaît avec une erreur de résolution, de connexion ou de certificat, examinez cette erreur depuis l’environnement WordPress. Une adresse que votre navigateur ouvre peut rester inaccessible à l’hébergement. Si un code HTTP apparaît, passez au relevé du récepteur. Ne changez pas le formulaire et les paramètres réseau dans le même essai. Le résultat doit permettre de situer la première étape qui échoue.
Observer le résultat HTTP sans consigner les champs
Si les traces habituelles sont insuffisantes et que le mainteneur confirme l’usage de l’API HTTP de WordPress, ajoutez ce diagnostic sur une copie autorisée. Il observe les réponses de cette API aux POST vers l’URL exacte configurée. Tout autre composant qui fait un POST à cette même adresse entre dans le périmètre. Utilisez donc un récepteur de recette et un chemin réservés à cet essai, sans secret dans l’URL. Identifiez le journal PHP utilisé par les requêtes web et vérifiez qu’il reste accessible aux seules personnes habilitées. Le fragment y inscrit un repère fixe, un code HTTP valide ou un libellé d’échec générique.
Sur la copie, placez le fragment dans wp-content/plugins/bpc-webhook-recette/bpc-webhook-recette.php. Remplacez l’URL d’exemple par l’adresse HTTPS directe du récepteur de recette, à l’identique de celle enregistrée dans l’action Webhook. Vérifiez qu’elle ne redirige pas vers une autre destination. Activez l’extension uniquement sur le site de l’essai, sans activation réseau en multisite. Notez l’heure, soumettez une seule valeur synthétique et cherchez le repère BPC webhook recette dans le journal PHP du processus web. Comparez l’heure et le résultat avec le relevé du récepteur.
Une ligne WP_Error signale un échec renvoyé par l’API HTTP, sans diagnostic détaillé. Un code HTTP indique une réponse reçue. Même un code 2xx demande une vérification du traitement côté récepteur. Sans ligne, vérifiez la méthode, l’URL exacte, l’activation sur le bon site et la destination du journal. Une intégration peut utiliser un autre client ou s’arrêter avant que WordPress déclenche cet événement. Après la comparaison, désactivez l’extension, retirez son fichier de la copie et conservez le repère et le résultat utiles au diagnostic.
<?php
/**
* Plugin Name: BPC Trace webhook de recette
*/
defined('ABSPATH') || exit;
add_action('http_api_debug', static function (
$response,
string $context,
string $_transport,
array $args,
string $url
): void {
$target = 'https://recepteur-recette.example/webhooks/elementor';
$method = strtoupper((string) ($args['method'] ?? ''));
if ('response' !== $context || $target !== $url || 'POST' !== $method) {
return;
}
if (is_wp_error($response)) {
error_log('[BPC webhook recette] WP_Error');
return;
}
$status = (string) wp_remote_retrieve_response_code($response);
if (preg_match('/^[1-5][0-9]{2}$/D', $status) !== 1) {
$status = 'absent ou non valide';
}
error_log('[BPC webhook recette] HTTP ' . $status);
}, 10, 5);Interpréter la réponse du récepteur
Rapprochez le code de réponse de l’observation du destinataire. Une réponse 401 ou 403 peut désigner une exigence d’authentification ou une règle de filtrage. Demandez le motif exact au responsable. Une réponse 404 peut provenir d’une ancienne destination ou d’un chemin d’essai désactivé. Une réponse 429 demande de vérifier la cadence et les limites documentées par le service. Une erreur 5xx oriente vers le récepteur ou un relais qui le précède. Conservez le message utile, avec les données du formulaire retirées du relevé.
Un succès HTTP peut indiquer que le service a accepté la demande. Vérifiez ensuite si son traitement a créé le dossier ou seulement enregistré une tâche. Une erreur de connexion ou une réponse perdue peut aussi laisser un doute sur l’effet déjà produit. Avant toute nouvelle tentative, demandez au destinataire de rechercher le marqueur dans ses traces. Pour un délai récurrent, mesurez où il se produit et consultez le contrat du récepteur. Une simple augmentation de délai ne garantit pas la bonne réception et peut rendre la soumission plus lente pour le visiteur.
Comparer le format du formulaire et le contrat du récepteur
Lorsque la tentative atteint le service mais échoue à la validation, comparez les champs réellement reçus à ceux qu’il attend. Vérifiez les identifiants du formulaire, les valeurs obligatoires et le format accepté. Un service peut demander une clé précise ou une structure qui n’est pas fournie telle quelle par la configuration actuelle. Utilisez un exemple synthétique visible par les deux équipes. Relevez aussi le type de contenu reçu et le nom des champs après éventuelle transformation. Une étiquette affichée au visiteur peut différer de l’identifiant utilisé pour faire la correspondance.
Si le service propose une table de correspondance, corrigez-la sur le circuit de test en conservant l’ancienne version. Si le format demandé exige une transformation que l’action disponible ne propose pas, faites préparer un relais maîtrisé ou une action adaptée par le mainteneur de l’intégration. Définissez le format, l’authentification, les limites et la réponse avant de changer le chemin. Vérifiez une valeur valide et une valeur volontairement invalide. Le récepteur doit pouvoir expliquer le refus et la soumission valide doit produire le résultat métier attendu.
Vérifier le traitement après la réception
Dans le service destinataire, retrouvez la demande par son heure et son marqueur. Ouvrez son état d’exécution et vérifiez l’étape où les champs sont transformés ou utilisés. Si le service accepte la demande puis lance un scénario, le résultat de ce scénario peut être en attente ou arrêté après une règle. Une fiche peut aussi être créée dans un espace différent de celui que l’équipe consulte. Comparez la destination configurée et la destination finale indiquée par le journal.
Vérifiez les filtres qui excluent des valeurs. Une règle peut ignorer volontairement les demandes dont un champ est vide. Un champ facultatif dans le formulaire peut être indispensable pour le scénario. Faites préciser ce besoin par les personnes qui utilisent les données. Choisissez ensuite si la validation doit être appliquée avant l’envoi ou dans le traitement du destinataire. Sur le circuit de test, vérifiez le résultat en présence et en absence de cette valeur. Le retour doit permettre de rétablir la règle précédente ou l’ancienne correspondance sans renvoyer les entrées déjà traitées.
Préparer une reprise sans rejouer toutes les entrées
Si l’incident a duré plusieurs heures, délimitez la période et le formulaire concernés. Comparez les entrées locales aux résultats confirmés chez le destinataire. Faites un relevé qui distingue les entrées reçues, celles dont la réception est incertaine et celles qui manquent. Utilisez un identifiant stable reconnu par le service, si disponible. Un nom ou une adresse peut apparaître dans plusieurs soumissions différentes. Lorsque le service accepte une clé d’idempotence, utilisez-la seulement selon sa documentation. Sinon, demandez au responsable comment reconnaître une entrée déjà traitée avant la reprise.
L’administration Elementor permet d’exporter des soumissions sélectionnées. Un export contient les données que des visiteurs ont confiées au formulaire. Gardez-le dans le stockage prévu et limitez-le au périmètre utile. Comparez le format au mécanisme de réimport autorisé du destinataire. Préparez une seule entrée synthétique de reprise sur le circuit isolé et vérifiez le résultat. Puis traitez les entrées effectivement manquantes avec un relevé après chaque lot. Si l’état d’une entrée reste incertain, isolez-la pour vérification au lieu de l’envoyer une deuxième fois avec le groupe confirmé.
Rétablir la configuration et retirer les traces d’essai
Conservez la version précédente du formulaire et les paramètres de correspondance du service. Pour annuler une modification de destination, remettez l’adresse approuvée par le responsable et vérifiez qu’elle est encore valable. Un secret révoqué demande une nouvelle valeur prévue par le service. Pour annuler une modification de format, remettez la version du formulaire et la règle de transformation compatibles entre elles. Après le retour, vérifiez le trajet avec une demande synthétique isolée.
Supprimez du circuit de test les données de contrôle qui n’ont plus d’usage selon la procédure du service. Retirez les traces temporaires contenant des champs de soumission ou un secret. Si un secret a été copié dans un endroit non prévu, demandez sa rotation au responsable du destinataire et vérifiez le formulaire avec la nouvelle valeur. Conservez seulement la preuve nécessaire, comme l’heure, le statut et l’identifiant de test. Une reprise réussie doit rester vérifiable sans que le ticket de dépannage devienne une nouvelle copie des données de contact.
Valider la chaîne de bout en bout
Préparez un essai qui reproduit la variante de page et les champs du parcours initial. Utilisez un navigateur de test et un récepteur isolé qui vous permet de lire les journaux. Gardez le même repère jusqu’à la création du résultat attendu.
- Confirmez que le widget effectivement servi contient l’action Webhook et la destination de test.
- Soumettez une seule demande synthétique et relevez son identifiant local si la collecte est active.
- Vérifiez la tentative sortante et son résultat dans les traces accessibles.
- Retrouvez la demande côté récepteur et vérifiez l’état du scénario puis le résultat métier.
- Comparez une demande valide et une demande qui doit être refusée par le contrat du récepteur.
- Vérifiez la méthode de reprise pour une entrée déjà traitée. Retirez le repère temporaire, remettez les réglages d’essai et consignez l’adresse de retour dans le stockage approuvé.
Documenter le formulaire et son destinataire
Notez le modèle qui fournit le formulaire, la variante de langue et le propriétaire de l’action Webhook. Conservez l’identifiant des champs importants et la règle qui les transforme au destinataire. Indiquez où vérifier chaque étape sans afficher les valeurs sensibles. Lors d’une migration de formulaire, la collecte locale peut encore fonctionner alors que le service distant attend une autre structure. Reprenez donc le test après un changement de modèle, de compte ou de destination.
La documentation d’Elementor décrit Webhook parmi les actions du widget de formulaire Pro. Vérifiez l’accès à cette fonction sur l’installation maintenue et le contrat propre au destinataire. Une autre extension n’est utile que si elle répond à un besoin établi, comme la transformation ou le suivi d’une livraison. Une notification de succès doit rester liée au résultat que l’équipe attend. Conservez un exemple de soumission de test, le code observé et l’identifiant du résultat distant. Ces trois repères permettent de reprendre l’enquête sans recopier toutes les données du formulaire.
