Symptôme
Un client du secteur du bâtiment nous a signalé, presque en passant, qu’il n’avait reçu aucune demande de devis depuis près d’un mois via son nouveau formulaire de contact, alors que son site headless en Next.js affichait bien un message de confirmation à chaque soumission testée. En vérifiant l’administration WordPress, les entrées du formulaire étaient pourtant bien présentes dans Gravity Forms : les visiteurs soumettaient réellement leurs demandes, mais aucun email de notification n’était jamais parti vers l’équipe commerciale.
Diagnostic
Le front Next.js soumettait le formulaire via l’API REST de Gravity Forms, activée par l’extension officielle gravityformsapi (aujourd’hui intégrée nativement), avec un appel de ce type :
POST /wp-json/gf/v2/forms/3/submissions
Authorization: Bearer <jeton signé>
Content-Type: application/json
{
"input_1": "Jean Dupuis",
"input_2": "jean.dupuis@exemple.fr",
"input_3": "Devis pour une extension de 30m²"
}
La soumission réussissait, avec un code 200 et un identifiant d’entrée renvoyé correctement. C’est précisément ce succès apparent qui a retardé le diagnostic : rien dans la réponse de l’API ne laissait supposer qu’une étape du traitement habituel avait été court-circuitée.
En reprenant la documentation de Gravity Forms de plus près, la cause est apparue : le point de terminaison REST de soumission, dans certaines versions de l’extension à l’époque de ce projet, n’exécutait pas systématiquement le hook gform_after_submission de la même manière qu’une soumission classique via le formulaire HTML natif de WordPress, ce hook étant justement celui qui déclenche l’envoi des notifications configurées dans l’administration.
Correctif
Plutôt que de dépendre du comportement interne de l’extension, potentiellement amené à changer d’une version à l’autre, le choix a été fait d’ancrer explicitement l’envoi de notification sur le hook natif, en vérifiant qu’il se déclenche bien après une soumission via l’API REST, avec un test de contrôle avant de considérer le correctif comme terminé :
add_action( 'gform_after_submission', function ( $entry, $form ) {
// Vérification explicite, journalisée, pour confirmer
// que ce hook se déclenche bien même via l'API REST.
error_log( sprintf(
'Soumission Gravity Forms #%d reçue pour le formulaire #%d',
$entry['id'],
$form['id']
) );
// Envoi manuel de secours si la notification native
// n'a pas été correctement configurée pour ce cas :
GFAPI::send_notifications( $form, $entry, 'form_submission' );
}, 10, 2 );
Après vérification en conditions réelles, il est apparu que le hook se déclenchait bien, mais que la notification elle-même avait été configurée avec une condition d’envoi (notification condition) qui testait la présence d’un champ caché normalement rempli par le formulaire HTML natif, un champ que l’appel direct à l’API REST ne renseignait jamais puisqu’il ne passait pas par le rendu du formulaire complet. La cause première n’était donc pas un hook manquant, mais une condition de notification pensée uniquement pour le parcours classique.
Prévention
- Toute condition d’envoi de notification configurée dans Gravity Forms est désormais systématiquement testée avec une soumission passant par l’API REST, pas uniquement avec le formulaire HTML natif.
- Un point de terminaison de test dédié, appelé automatiquement après chaque déploiement, envoie une soumission factice et vérifie dans les journaux qu’une notification a bien été déclenchée.
- Le client a été informé de vérifier ponctuellement, lui aussi, que les emails arrivent bien, plutôt que de se reposer uniquement sur le message de confirmation affiché côté front, qui ne garantit en rien l’envoi effectif d’une notification.
Un message de confirmation affiché côté front ne prouve jamais qu’une notification est réellement partie côté serveur : ce sont deux étapes distinctes, à tester séparément.
En résumé
Trois semaines de demandes de devis se sont perdues silencieusement, non pas à cause d’un bug caché dans l’extension, mais à cause d’une condition de notification héritée du formulaire natif, jamais adaptée au nouveau parcours de soumission via l’API REST. La leçon la plus utile ici dépasse Gravity Forms : chaque automatisation existante (notification, webhook, intégration tierce) doit être revérifiée dès qu’un nouveau canal de soumission est ajouté, même si l’API elle-même répond correctement.
