Gravity Forms contre Contact Form 7 : ce que le code révèle

Comparer deux extensions de formulaires à partir de leur page de présentation ne dit pas grand chose : les deux permettent de créer un formulaire, de recevoir un message, d'ajouter des champs. Les différences qui comptent apparaissent ailleurs, dans la façon dont les données sont stockées, dans les points d'extension offerts au développeur, dans ce qui est chargé côté visiteur et dans le coût de maintenance à trois ans. Cet article compare ces deux solutions sur ces critères techniques, sans conclure qu'une est meilleure : elles répondent à des besoins différents et le choix dépend surtout de ce que le projet devra faire dans deux ans.

Le stockage des soumissions

C'est la différence structurelle la plus importante et celle qui détermine l'essentiel des autres. Les deux solutions n'ont pas la même conception de ce qu'est un formulaire : l'une le considère comme un moyen d'envoyer un message, l'autre comme un outil de collecte de données. Cette divergence philosophique se traduit très concrètement dans la base. Les principes de mise en place de la solution la plus complète sont présentés dans notre article sur l'installation et la création d'un formulaire Gravity Forms.

Le modèle sans stockage

La solution la plus légère ne conserve rien par défaut : le formulaire est soumis, un courriel part, et la donnée disparaît. Cette approche a des mérites réels, elle réduit la surface de données personnelles conservées et elle simplifie la conformité. Elle présente un inconvénient majeur : un courriel perdu, filtré comme indésirable ou envoyé à une adresse obsolète est une demande client définitivement perdue. Ce cas se produit plus souvent qu'on ne le croit et il est indétectable, puisqu'aucune trace n'existe. Un client qui vous reproche de ne pas avoir répondu à une demande dont vous n'avez jamais eu connaissance illustre parfaitement le problème.

Le modèle avec entrées

La solution la plus complète enregistre chaque soumission dans ses propres tables, avec ses champs, ses métadonnées et son statut. Le courriel devient une notification et non le support de l'information. Une demande reste consultable même si aucun message n'est arrivé, ce qui change complètement la fiabilité du dispositif. Ce stockage a un coût : il faut gérer la durée de conservation, la purge et les droits d'accès, questions que nous développons dans notre article sur la conservation et la purge des entrées Gravity Forms.

Les tables dédiées

Le stockage en tables propres, plutôt que dans les tables génériques de WordPress, présente un avantage de performance considérable sur les formulaires très soumis. Une table dédiée avec ses index se lit rapidement même avec des centaines de milliers d'entrées. Les extensions stockant les soumissions comme des contenus alourdissent en revanche les tables communes, ce qui ralentit l'ensemble du site. Cette différence est invisible sur un formulaire de contact recevant dix messages par mois et déterminante sur une inscription à un événement. Elle se mesure facilement en comparant le poids des tables avant et après quelques semaines d'usage intensif.

L'export des données

Une solution stockant les entrées propose un export vers un tableur, filtré par date et par formulaire. Cette fonction est celle que les équipes réclament en premier après quelques mois d'usage. La reconstituer sur une solution sans stockage suppose de retrouver les courriels, ce qui n'est pas une méthode. C'est souvent l'argument qui fait basculer le choix a posteriori, une fois le formulaire déjà en production. La migration est alors possible et elle ne récupère évidemment aucune des soumissions passées.

Le droit d'accès et l'effacement

La conservation des soumissions crée des obligations : une personne peut demander une copie de ses données ou leur effacement. Une solution stockant les entrées permet de retrouver et de supprimer ces enregistrements en quelques clics. Une solution sans stockage n'a rien à effacer côté site, ce qui simplifie la réponse et déplace la question vers la messagerie. Nous ne sommes pas juristes et l'appréciation de ces obligations relève d'un conseil compétent selon le contexte.

La question du volume

Un site collectant plusieurs milliers d'entrées par mois doit prévoir une purge automatique, faute de quoi les tables grossissent indéfiniment. Cette purge est proposée nativement par les solutions les plus complètes, avec un délai paramétrable. Son absence sur les autres n'est pas un problème puisqu'elles ne stockent rien. Le volume attendu constitue donc un critère de choix à part entière, souvent négligé au moment de la décision initiale. Poser la question du nombre de soumissions mensuelles attendues, dès le cahier des charges, oriente immédiatement le choix.

Les points d'extension

La capacité à intercepter le traitement conditionne tout ce que le projet pourra faire au delà de l'envoi d'un message. C'est le critère le plus important pour un développement sur mesure.

Les accroches disponibles

Les deux solutions exposent des points d'accroche, avec des granularités très différentes. La plus complète en propose plusieurs centaines, couvrant chaque étape du cycle de vie : avant validation, après validation, avant enregistrement, après enregistrement, avant notification, après notification. La plus légère en propose quelques dizaines, suffisantes pour les cas courants et vite limitantes dès que le besoin sort de l'ordinaire. Cet écart se ressent immédiatement sur un projet ayant des règles métier. Il ne se ressent pas du tout sur un formulaire de contact, ce qui explique que les retours d'expérience se contredisent selon les projets.

La validation personnalisée

Ajouter une règle de validation propre au métier, vérifier un numéro de client, contrôler une disponibilité, refuser une combinaison de champs, demande un point d'accroche sur la validation. Les deux solutions le permettent, avec une différence notable sur la restitution du message d'erreur au bon champ. Cette restitution fine est ce qui distingue un formulaire agréable d'un formulaire pénible. Elle est nettement mieux traitée sur la solution la plus complète. Un message générique en haut du formulaire oblige le visiteur à chercher lui même ce qui ne va pas, ce qui augmente sensiblement les abandons.

Les champs personnalisés

Créer un type de champ propre au projet, avec son affichage et sa validation, est possible sur les deux et avec des efforts très différents. L'une propose une classe à étendre et une documentation dédiée, l'autre demande de bricoler autour des mécanismes existants. Sur un projet où deux ou trois champs métier sont nécessaires, cette différence représente plusieurs journées de développement. Elle doit être évaluée avant de choisir. Le meilleur moyen consiste à écrire un champ de test avant de s'engager, exercice d'une demi journée qui répond définitivement à la question.

La logique conditionnelle

Afficher un champ selon la réponse à un autre est une fonction native sur l'une et une extension à ajouter sur l'autre. Cette différence paraît mineure et elle structure la conception des formulaires longs. Un formulaire de devis comportant huit branches selon le type de projet devient impraticable sans cette fonction. Le réglage se fait champ par champ, en désignant la condition qui déclenche l'affichage, ce qui reste lisible tant que les branches ne s'imbriquent pas trop profondément. Au delà de trois niveaux, mieux vaut découper le formulaire en plusieurs étapes.

Les connexions à des services

Envoyer une soumission vers un outil de gestion de la relation client, une plateforme d'envoi de courriels ou une interface métier se fait par des modules dédiés ou par du code. Les modules officiels sont nombreux sur la solution commerciale et rares sur l'autre, ce qui reporte le travail sur le développement. Un appel d'interface écrit à la main reste parfaitement faisable dans les deux cas. La question est de savoir qui le maintiendra lorsque le service tiers modifiera son interface. Un module officiel déplace cette charge vers l'éditeur, ce qui constitue une part importante de la valeur de l'abonnement.

La documentation des accroches

Une documentation complète, avec exemples et signatures de fonctions, fait gagner des heures. Sur ce point, l'écart est net et il s'explique par le modèle économique : une extension commerciale finance sa documentation. La communauté compense partiellement sur l'autre, avec des ressources dispersées de qualité variable. Ce critère pèse davantage qu'on ne l'imagine sur le coût réel d'un développement. Une heure passée à chercher le bon point d'accroche coûte plus cher qu'une année d'abonnement sur un projet un peu ambitieux.

Ce qui arrive côté visiteur

Le poids et le comportement du formulaire dans le navigateur constituent un critère souvent oublié, alors qu'ils touchent chaque visiteur de chaque page où le formulaire apparaît.

Le poids chargé

La solution légère charge quelques dizaines de kilooctets, la solution complète plusieurs centaines lorsque toutes ses fonctions sont actives. Sur une page de contact isolée, cette différence est sans conséquence. Sur un formulaire présent dans le pied de page de tout le site, elle se paie sur chaque consultation. Le critère à examiner est donc la présence du formulaire plutôt que son poids absolu. Un formulaire de contact placé sur toutes les pages mérite d'être remplacé par un lien vers une page dédiée.

Le chargement conditionnel

Les deux solutions permettent de ne charger leurs ressources que sur les pages contenant réellement un formulaire, réglage qui n'est pas toujours actif par défaut. Le vérifier après installation est le premier geste à faire. Sur un site où le formulaire n'apparaît que sur deux pages, ce réglage divise par cinquante l'impact sur le reste du site. C'est probablement l'optimisation la plus rentable du sujet. Elle prend trente secondes et elle est absente de la majorité des installations examinées.

La dépendance à une bibliothèque

Les deux solutions s'appuient sur une bibliothèque JavaScript ancienne, chargée par WordPress pour des raisons de compatibilité. Cette dépendance est un frein sur les projets cherchant à s'en affranchir. Aucune des deux ne permet aujourd'hui de s'en passer complètement, ce qui relativise la comparaison sur ce point. Le sujet mérite d'être vérifié à chaque version majeure, la tendance générale étant à la réduction de cette dépendance. Cette bibliothèque restant chargée pour d'autres raisons sur la plupart des sites, son coût marginal est en pratique nul.

Le comportement sans script

Un formulaire qui ne fonctionne pas avec le JavaScript désactivé exclut une petite part des visiteurs et complique les tests automatisés. Les deux solutions dégradent différemment, l'une restant globalement fonctionnelle et l'autre perdant sa logique conditionnelle. Ce critère est marginal sur un site grand public et il compte sur un site à exigence d'accessibilité forte. Il mérite d'être testé plutôt que supposé. Désactiver le JavaScript dans un navigateur et soumettre le formulaire donne la réponse en une minute.

L'accessibilité

La qualité du balisage produit, association des étiquettes aux champs, restitution des erreurs, navigation au clavier, varie sensiblement d'une version à l'autre. Les deux solutions ont progressé et aucune n'est parfaite. Un audit rapide sur un formulaire réel, avec un lecteur d'écran, donne une réponse en quinze minutes. Ce test doit être fait sur le projet plutôt que sur la base de déclarations générales. La restitution des messages d'erreur aux technologies d'assistance est le point qui pose le plus souvent problème.

La protection contre les envois automatisés

Les deux proposent des mécanismes de filtrage, champ piège et intégration avec des services de vérification. La différence porte sur la finesse du réglage et sur la disponibilité de solutions ne dépendant pas d'un service tiers. Un champ piège, invisible pour un humain et rempli par un robot, constitue la première ligne de défense et il ne demande aucun service extérieur. Il suffit à écarter l'essentiel des envois automatisés les plus grossiers. Le sujet mérite d'être traité dès la mise en ligne, un formulaire non protégé recevant des soumissions automatisées en quelques jours. Le volume reçu ne dépend pas de la fréquentation du site, les robots parcourant systématiquement les formulaires qu'ils trouvent.

Choisir selon le projet

La comparaison n'a de sens que rapportée à un usage. Quelques situations types permettent de trancher rapidement.

Le formulaire de contact simple

Un site vitrine avec un unique formulaire de contact n'a besoin d'aucune fonction avancée. La solution légère convient parfaitement, coûte zéro et se maintient sans effort. Y ajouter une solution commerciale reviendrait à payer un abonnement pour recevoir trois messages par mois. Le seul point à traiter est la fiabilité de la réception, qui se règle en configurant correctement l'expédition des courriels. Un service d'expédition dédié, plutôt que l'envoi direct depuis le serveur, améliore considérablement la délivrabilité.

La collecte structurée

Dès qu'il s'agit d'inscriptions, de candidatures ou de demandes de devis à traiter dans le temps, le stockage devient indispensable. La consultation, le filtrage et l'export sont alors des fonctions quotidiennes et non des options. Le coût de l'abonnement se compare au temps qu'il fait gagner, comparaison qui tourne rapidement en sa faveur. C'est le cas où le choix ne se discute pas vraiment. Une demi journée par mois économisée sur le traitement des demandes rembourse largement l'abonnement annuel.

Le formulaire long et conditionnel

Un questionnaire à branches, un configurateur ou une demande complexe demande une logique conditionnelle native et une validation fine. Reproduire cela sur la solution légère est possible et coûteux, et le résultat sera plus fragile. Ce type de projet oriente sans ambiguïté vers la solution la plus complète. Il faut simplement prévoir le temps de conception du formulaire lui même, qui dépasse souvent le temps technique. Dessiner l'arborescence des questions avant de toucher à l'outil évite de reconstruire le formulaire trois fois.

Le besoin d'intégration

Une soumission qui doit alimenter un outil externe se traite plus vite avec les modules officiels, à condition qu'un module existe pour l'outil visé. Vérifier ce point avant de choisir évite de découvrir qu'il faudra développer malgré l'abonnement. Lorsque l'intégration passe de toute façon par du code, l'avantage se réduit aux points d'accroche disponibles. Ce cas est plus fréquent qu'il n'y paraît, les outils métier propres à un secteur disposant rarement d'un module tout prêt.

Le budget et la maintenance

Une extension commerciale implique un abonnement annuel à renouveler, faute de quoi les mises à jour cessent. Cette dépendance budgétaire doit être annoncée au client et inscrite dans le budget récurrent du site. Un abonnement oublié produit une extension figée sur une version ancienne, ce qui devient un risque de sécurité. C'est un point de gestion plus que de technique et il est régulièrement négligé, comme nous l'évoquons dans notre article sur la création d'un formulaire gratuit avec Contact Form 7.

La reprise par un tiers

Un site repris par un autre prestataire se transmet plus facilement avec une solution largement répandue et documentée. Les deux le sont, ce qui neutralise ce critère, à une nuance près : les développements spécifiques faits autour d'une extension commerciale supposent que le repreneur dispose d'une licence pour travailler. Ce détail se règle en transférant la licence au client plutôt qu'en la conservant côté agence. C'est une bonne pratique qui évite des situations désagréables.