# Formulaires Elementor Pro : webhooks et action après envoi personnalisée

> Envoyer les données d'un formulaire Elementor Pro vers un webhook ou un CRM maison, sans plugin tiers, grâce à une action après envoi sur mesure.

- Auteur : Clément Hadrot
- Publié le : 2020-03-11
- Mis à jour le : 2020-03-11
- Catégorie : Elementor
- URL : https://wpmoderne.dev.wordpress-developpement.fr/elementor/formulaires-elementor-webhooks-action-personnalisee/

## L’essentiel

- L'action Webhook native suffit pour 80 % des cas
- Action_Base permet une logique métier propre
- Les échecs d'envoi doivent être journalisés, jamais silencieux

Un client nous a demandé, la semaine dernière, de brancher son formulaire de devis Elementor Pro sur un CRM interne qui n'a jamais entendu parler de Zapier. Pas de connecteur tout fait, pas de budget pour un service tiers : il fallait envoyer chaque soumission vers une URL interne, avec un format précis. Bonne nouvelle, Elementor Pro gère ce cas depuis longtemps, à deux niveaux différents.

Le premier niveau est visible dans l'éditeur : l'action « Webhook », disponible dans l'onglet Actions After Submit de n'importe quel formulaire. Le second, plus robuste et surtout personnalisable, consiste à écrire sa propre action PHP en étendant la classe abstraite `Action_Base`. Nous allons voir les deux, et pourquoi le second l'emporte dès que la logique dépasse un simple POST.

## L'action Webhook native, pour aller vite

Dans l'éditeur, sélectionnez le widget Formulaire, ouvrez l'onglet **Actions After Submit** et cochez **Webhook**. Un champ URL apparaît : Elementor Pro y envoie une requête POST contenant tous les champs du formulaire, sérialisés en `form_fields`, accompagnés de métadonnées (IP, user agent, page source).

- Aucune ligne de code n'est nécessaire.
- Le format des données n'est pas configurable : c'est à prendre ou à laisser côté CRM.
- Les erreurs HTTP ne sont pas remontées à l'utilisateur qui soumet le formulaire.

Pour un simple relais vers un outil qui accepte du JSON brut, c'est parfait. Notre client avait besoin d'un format différent, avec un identifiant de contact recalculé côté serveur : il fallait passer à une action personnalisée.

## Créer une classe Action_Base

Elementor Pro expose un système d'actions enregistrables, exactement comme les widgets. Chaque action après envoi (Email, Redirect, Webhook…) est une classe qui étend `\ElementorPro\Modules\Forms\Classes\Action_Base`. Voici le squelette minimal d'une action qui pousse les données vers notre CRM interne :

```
<?php
use ElementorPro\Modules\Forms\Classes\Action_Base;
use ElementorPro\Modules\Forms\Classes\Form_Record;
use ElementorPro\Modules\Forms\Classes\Ajax_Handler;

class Action_After_Submit_Crm_Maison extends Action_Base {

    public function get_name() {
        return 'crm_maison';
    }

    public function get_label() {
        return __( 'CRM maison', 'wpm-forms' );
    }

    public function run( $record, $ajax_handler ) {
        $raw_fields = $record->get( 'fields' );
        $fields = [];
        foreach ( $raw_fields as $id => $field ) {
            $fields[ $id ] = $field['value'];
        }

        $response = wp_remote_post( 'https://crm.interne.test/api/leads', [
            'timeout' => 8,
            'headers' => [ 'Content-Type' => 'application/json' ],
            'body'    => wp_json_encode( [
                'source' => get_permalink( $record->get( 'post_id' ) ),
                'champs' => $fields,
            ] ),
        ] );

        if ( is_wp_error( $response ) ) {
            error_log( 'CRM maison : envoi échoué - ' . $response->get_error_message() );
        }
    }

    public function register_settings_section( $widget ) {}
    public function on_export( $element ) {}
}
```

> L'essentiel à retenir : L'action Webhook native suffit pour 80 % des cas ; Action_Base permet une logique métier propre ; Les échecs d'envoi doivent être journalisés, jamais silencieux

Trois méthodes sont réellement obligatoires : `get_name()`, `get_label()` et `run()`. Les deux dernières peuvent rester vides si l'action n'ajoute aucun contrôle dans l'éditeur, ce qui est le cas ici puisque l'URL est codée côté serveur.

## Enregistrer l'action auprès d'Elementor Pro

Une classe seule ne sert à rien tant qu'elle n'est pas déclarée. Cela se fait via le hook `elementor_pro/forms/actions/register`, qui reçoit le gestionnaire d'actions en argument :

```
add_action( 'elementor_pro/forms/actions/register', function( $form_actions_registrar ) {
    require_once __DIR__ . '/class-action-crm-maison.php';
    $form_actions_registrar->register( new Action_After_Submit_Crm_Maison() );
} );
```

Une fois ce code déposé dans le thème enfant (ou un petit plugin maison, ce que nous préférons pour ce genre de logique métier), l'action « CRM maison » apparaît dans la liste des Actions After Submit de chaque formulaire, au même titre que Email ou Redirect. Il suffit de la cocher.

## Gérer les échecs proprement

Le piège classique : une soumission qui échoue côté CRM sans que personne ne s'en aperçoive, parce que l'utilisateur voit quand même le message de succès d'Elementor. Nous recommandons systématiquement d'ajouter, en plus du `error_log()`, une notification interne :

- Enregistrer les échecs dans une table dédiée ou un fichier de log tournant.
- Déclencher un e-mail d'alerte à l'équipe si le code HTTP retourné n'est pas 2xx.
- Prévoir un mécanisme de rejeu manuel pour les leads perdus, plutôt que de les laisser disparaître.

> Sur un projet e-commerce, nous avons vu deux semaines de demandes de devis se perdre silencieusement parce que le endpoint du CRM avait changé de certificat SSL. Depuis, toute action after submit critique embarque une alerte par e-mail en cas d'échec.

## En résumé

L'action Webhook native convient pour un simple relais de données brutes. Dès que la logique se complique — reformatage, calcul d'un identifiant, appel à plusieurs services — la classe `Action_Base` est le bon outil : elle s'intègre nativement dans l'éditeur, elle est enregistrée une seule fois via `elementor_pro/forms/actions/register`, et elle vit dans un code versionné plutôt que dans un champ texte de l'interface. Pensez simplement à toujours journaliser les échecs : un formulaire qui « fonctionne » côté visiteur mais ne livre rien côté CRM est le pire des bugs, invisible jusqu'à ce qu'un client s'étonne de ne jamais être rappelé.