Un client qui gère un réseau de neuf sites vitrine pour des agences immobilières nous a demandé de choisir une extension de formulaires unique pour homogénéiser l’ensemble. La question n’était pas « laquelle est la plus jolie » mais « laquelle s’intègre le mieux avec nos automatisations existantes et nos développements sur mesure ». On a donc comparé Gravity Forms, WPForms et Fluent Forms sous l’angle du développeur, pas seulement de l’utilisateur final.
Les trois extensions couvrent le même besoin de base — construire un formulaire par glisser-déposer et recevoir des soumissions — mais leurs choix d’architecture divergent nettement dès qu’on sort du cas d’usage standard.
Stockage des entrées : trois philosophies
Gravity Forms stocke les entrées dans ses propres tables, wp_gf_entry et wp_gf_entry_meta, séparées de wp_posts depuis longtemps. C’est un choix qui a bien vieilli : les tables sont indexées pour la recherche et le tri, et l’extension expose une API de requêtage propre via GFAPI::get_entries().
Fluent Forms suit une logique proche, avec ses propres tables wp_fluentform_submissions et wp_fluentform_entry_details, pensées dès la conception pour rester légères. C’est d’ailleurs l’argument marketing principal de l’extension : moins de surcharge en base par rapport aux concurrents historiques.
WPForms, à l’inverse, stocke chaque soumission comme un article du post type wpforms_entry, avec les données du formulaire sérialisées dans un champ meta. C’est plus proche des habitudes WordPress classiques, donc plus simple à comprendre pour qui connaît déjà l’API WP_Query, mais moins optimisé pour de gros volumes : une recherche sur une valeur de champ nécessite de désérialiser potentiellement beaucoup d’entrées.
Richesse des hooks disponibles
C’est là que Gravity Forms garde une avance construite sur plus d’une décennie de terrain. L’extension expose des centaines de hooks documentés : gform_pre_submission, gform_after_submission, gform_validation, gform_entry_post_save, chacun avec une granularité par formulaire (gform_pre_submission_{$form_id}). L’API PHP GFAPI permet de créer des formulaires par code, de modifier des champs par programmation, et de scripter des migrations complètes.
Fluent Forms propose une architecture de hooks plus récente mais bien pensée, calquée sur les usages modernes : fluentform/before_insert_submission, fluentform/submission_inserted, fluentform/validation_errors. Le code est objet de bout en bout, ce qui facilite l’extension par composition plutôt que par rustines successives.
WPForms limite l’accès aux hooks les plus utiles à sa version Pro, et sa documentation développeur reste plus mince que celle de Gravity Forms. Les actions existent (wpforms_process_complete, wpforms_process_before), mais l’écosystème de tutoriels et d’exemples publics est nettement moins fourni.
| Critère | Gravity Forms | WPForms | Fluent Forms |
|---|---|---|---|
| Stockage des entrées | Tables dédiées | Post type + meta | Tables dédiées, légères |
| API de requêtage | GFAPI, très complète | Limitée, orientée UI | Repositories orientés service |
| Hooks documentés | Très nombreux, matures | Corrects, peu documentés | Modernes, en croissance |
| Poids en base sur gros volume | Bon | Se dégrade vite | Très bon |
| Licence de développement | Payante dès le départ | Payante pour l’API avancée | Version gratuite généreuse |
Performance sur les sites à fort trafic
Sur nos neuf sites d’agences immobilières, la charge principale venait des formulaires de contact et d’estimation, avec des pics lors des campagnes publicitaires locales. Le stockage en tables dédiées de Fluent Forms et Gravity Forms s’est montré nettement plus stable que le post type de WPForms sur des tests de charge synthétiques à 500 soumissions simultanées : le temps de traitement moyen restait sous 200 ms pour les deux premiers, contre une dérive perceptible pour WPForms au-delà de quelques milliers d’entrées cumulées sans purge.
Un exemple concret : accrocher un webhook CRM
// Fluent Forms : envoyer chaque soumission vers un CRM externe
add_action( 'fluentform/submission_inserted', function( $entryId, $formData, $form ) {
wp_remote_post( 'https://crm.exemple.fr/api/leads', array(
'body' => wp_json_encode( $formData ),
'headers' => array( 'Content-Type' => 'application/json' ),
'timeout' => 8,
) );
}, 10, 3 );
L’équivalent chez Gravity Forms (gform_after_submission) et chez WPForms (wpforms_process_complete) suit le même schéma général, mais les signatures et les formats de données diffèrent sensiblement, ce qui rend une migration d’une extension à l’autre plus coûteuse qu’il n’y paraît si beaucoup d’automatisations personnalisées existent déjà.
Notre verdict
Pour un projet où le développement sur mesure et les automatisations pèsent lourd, Gravity Forms reste le choix le plus sûr grâce à la maturité de son API, malgré un coût de licence plus élevé. Fluent Forms est une alternative sérieuse et moins chère, avec une architecture de stockage tout aussi robuste et des hooks bien conçus, en particulier pour un projet démarré récemment. WPForms garde son intérêt pour des besoins simples où la facilité de configuration prime sur l’extensibilité, mais nous ne le recommandons pas dès que le projet prévoit des intégrations personnalisées ou un volume de soumissions important. Sur le réseau de neuf sites, le choix s’est porté sur Fluent Forms, pour son rapport entre performance et coût de licence sur un parc multisite.
