62 % des soumissions du formulaire de contact disparaissaient silencieusement depuis la migration vers l’éditeur V4, en accès anticipé sur ce projet. La cause : le plugin tiers qui reliait jusque-là le formulaire Elementor à HubSpot s’appuyait sur des hooks internes propres à l’architecture V3, invisibles pour l’architecture atomique de la V4.
Plutôt que d’attendre une hypothétique mise à jour de ce plugin, la décision a été prise de reconstruire la connexion directement, sans dépendance tierce, en appelant l’API Forms de HubSpot depuis un composant de formulaire natif de l’éditeur V4. Ce billet documente cette reconstruction technique, sans entrer dans la configuration du CRM HubSpot lui-même ni dans la conception des workflows marketing qui exploitent ensuite ces données, deux sujets qui dépassent le cadre de cet article.
Pourquoi le pont existant a cessé de fonctionner
Le plugin tiers utilisé jusqu’alors s’accrochait au hook elementor_pro/forms/new_record, déclenché après la soumission d’un formulaire construit avec le widget Formulaire d’Elementor Pro en architecture V3. Sous l’architecture atomique testée en V4, le composant de formulaire ne déclenche plus ce hook de la même façon : la logique de soumission a été redécoupée entre plusieurs sous-composants, et le format des données transmises a changé.
Plutôt que de tenter de rattraper ce hook devenu incertain, la solution retenue s’appuie sur un point de terminaison REST WordPress personnalisé, appelé directement en JavaScript depuis le composant de formulaire V4 au moment de la soumission.
Construire le point de terminaison REST côté WordPress
Ce point de terminaison reçoit les données du formulaire, les valide, puis les transmet à l’API Forms de HubSpot :
add_action( 'rest_api_init', function() {
register_rest_route( 'wpmoderne/v1', '/hubspot-submit', [
'methods' => 'POST',
'callback' => 'wpmoderne_submit_to_hubspot',
'permission_callback' => '__return_true',
] );
} );
function wpmoderne_submit_to_hubspot( WP_REST_Request $request ) {
$email = sanitize_email( $request->get_param( 'email' ) );
$name = sanitize_text_field( $request->get_param( 'name' ) );
if ( ! is_email( $email ) ) {
return new WP_Error( 'invalid_email', 'Adresse e-mail invalide.', [ 'status' => 400 ] );
}
$response = wp_remote_post(
'https://api.hsforms.com/submissions/v3/integration/submit/PORTAL_ID/FORM_GUID',
[
'body' => wp_json_encode( [
'fields' => [
[ 'name' => 'email', 'value' => $email ],
[ 'name' => 'firstname', 'value' => $name ],
],
] ),
'headers' => [ 'Content-Type' => 'application/json' ],
]
);
if ( is_wp_error( $response ) ) {
return new WP_Error( 'hubspot_error', 'Échec de la soumission à HubSpot.', [ 'status' => 502 ] );
}
return [ 'status' => 'ok' ];
}Appeler ce point de terminaison depuis le composant V4
Côté éditeur V4, le composant de formulaire expose un événement de soumission personnalisable, sur lequel il est possible d’attacher un gestionnaire JavaScript pour intercepter l’envoi avant qu’il ne suive son comportement par défaut :
document.addEventListener('elementor/frontend/form-submit', async (event) => {
const { email, name } = event.detail.fields;
const response = await fetch('/wp-json/wpmoderne/v1/hubspot-submit', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ email, name }),
});
if (!response.ok) {
console.error('Échec de la synchronisation HubSpot');
}
});L’API exacte de l’événement elementor/frontend/form-submit reste susceptible d’évoluer tant que l’éditeur V4 est en accès anticipé : il est recommandé de vérifier ce nom d’événement à chaque montée de version durant cette phase, la documentation officielle des composants V4 n’étant pas encore stabilisée.
Ce que cette approche apporte par rapport à un plugin tiers
- Aucune dépendance à un plugin dont la compatibilité V4 reste incertaine
- Un contrôle complet sur la validation des données avant transmission à HubSpot
- Une gestion d’erreur explicite plutôt qu’un échec silencieux invisible pour l’utilisateur du CRM
Le principal inconvénient reste la maintenance : ce code doit être surveillé à chaque mise à jour de l’éditeur V4, tant que son architecture interne continue d’évoluer avant sa stabilisation officielle.
Notre position sur ce type de pont : mieux vaut un point de terminaison REST maison, simple et documenté en interne, qu’un plugin tiers dont on ne maîtrise ni le code ni le rythme de mise à jour.
En résumé
La migration d’une intégration HubSpot vers l’éditeur V4 d’Elementor a montré les limites des ponts construits sur des hooks internes propres à l’architecture V3. Un point de terminaison REST WordPress personnalisé, appelé directement depuis le composant de formulaire V4, offre une solution plus robuste et plus simple à faire évoluer, au prix d’une vigilance accrue tant que l’architecture atomique n’est pas définitivement figée.
