Comment récupérer un formulaire de demande détaillée — dimensions, options, contraintes du client — sans que le client passe directement par la fiche produit standard, tout en gardant WooCommerce comme moteur de commande et de paiement final ? Une agence confrontée à ce besoin, pour un client vendant des installations sur mesure, a comparé deux constructeurs de formulaires capables de créer une commande WooCommerce en brouillon à partir d’une soumission : Fluent Forms et WPForms.
Les deux proposent une intégration WooCommerce, mais avec des philosophies différentes qui pèsent lourd une fois le formulaire complexifié au-delà d’un simple champ de contact.
Fluent Forms : plus de hooks, plus de contrôle
Fluent Forms expose une série d’actions déclenchées à chaque étape du traitement d’une soumission, ce qui permet d’intervenir précisément sur la création de la commande WooCommerce associée : ajouter des métadonnées personnalisées à la commande, choisir dynamiquement le produit ajouté selon les réponses du formulaire, ou déclencher un e-mail interne différent selon la complexité de la demande.
add_action( 'fluentform/submission_inserted', function ( $entry_id, $form_data, $form ) {
if ( 25 !== (int) $form['id'] ) {
return;
}
$order = wc_create_order();
$order->add_product( wc_get_product( 4821 ), 1 );
$order->update_meta_data( '_details_sur_mesure', $form_data['details_projet'] );
$order->set_status( 'wc-en-attente-devis' );
$order->save();
}, 10, 3 );
WPForms : plus rapide pour un besoin simple
WPForms, via son extension officielle dédiée à WooCommerce, propose un réglage plus guidé par l’interface d’administration : associer un champ de formulaire à un produit, définir une correspondance entre une option de sélection et une variation de produit, sans nécessairement écrire de code personnalisé. Pour un formulaire ponctuel qui ne demande pas de logique métier particulière, c’est objectivement le chemin le plus rapide vers une mise en production.
Où WPForms montre ses limites
Dès que le besoin dépasse une simple correspondance champ-produit — par exemple choisir dynamiquement le statut initial de la commande selon la complexité estimée de la demande, ou enrichir la commande avec des métadonnées calculées à partir de plusieurs champs combinés — WPForms impose de passer par des hooks PHP moins nombreux et moins documentés que ceux de Fluent Forms, ce qui rallonge le développement personnalisé.
| Critère | Fluent Forms | WPForms |
|---|---|---|
| Hooks disponibles pour personnalisation | Nombreux et documentés | Plus restreints |
| Mise en place sans code | Possible mais moins guidée | Très guidée par l’interface |
| Contrôle du statut de commande créé | Total via hook | Limité aux réglages proposés |
| Coût pour un formulaire simple | Équivalent | Équivalent |
Le critère qui a tranché
Pour cette agence, le besoin réel dépassait un simple mappage champ-produit : la commande générée devait porter un statut personnalisé « en attente de devis », des métadonnées structurées reprenant l’ensemble des réponses, et déclencher une notification différente selon un score de complexité calculé à partir de plusieurs champs. Ce niveau de logique a fait pencher la balance vers Fluent Forms, dont les hooks couvraient directement ce scénario sans contournement.
- Besoin de logique métier au-delà d’un mappage simple : favorise Fluent Forms.
- Formulaire ponctuel, sans traitement particulier de la commande : WPForms suffit.
- Équipe technique disponible pour écrire des hooks personnalisés : condition nécessaire pour Fluent Forms.
Ce que ce choix ne couvre pas
La validation du paiement associé à la commande générée reste identique quel que soit le constructeur retenu : les deux s’appuient sur le tunnel de paiement natif de WooCommerce une fois la commande créée, et aucun des deux n’introduit de logique de paiement propre.
Le bilan de cette comparaison
Entre les deux, il n’existe pas de réponse universelle : Fluent Forms gagne dès que la commande générée doit porter une logique métier propre au projet, WPForms reste largement suffisant — et souvent plus rapide à déployer — pour un formulaire qui se contente d’alimenter une commande standard sans traitement particulier.
