Générateur de formulaires par glisser-déposer : tickets et enquêtes sans formulaire de contact 7

La semaine dernière je comptais les plugins sur un de mes sites clients. Une boutique WooCommerce ordinaire, du matériel industriel, rien d'exotique. Et donc je regarde la liste des plugins actifs - et il y a Contact Form 7 pour un formulaire de commentaires, Conditional Fields, Flamingo pour stocker des applications, File Upload pour télécharger des fichiers et, cerise sur le gâteau, une sorte de module complémentaire payant pour un beau design, car les formulaires CF7 standard semblent avoir été créés en 1998. Cinq plugins. Cinq points d’échec potentiels. Cinq sources de mise à jour, chacune pouvant casser quelque chose. Et tout cela pour que le client puisse écrire « Je veux connaître le prix de l’huile hydraulique, voici mon numéro de téléphone ».

Ensuite, j'ai pensé : pourquoi est-ce arrivé ? Pourquoi la communauté WordPress est-elle habituée au fait que pour résoudre un problème, il faut assembler un constructeur à partir de cinq ou six plugins différents, chacun étant écrit par un auteur différent, mis à jour à des moments différents et compatible avec les autres seulement tant que personne n'a rien mis à jour ? Après tout, un formulaire de commentaires est apparemment l’un des éléments les plus élémentaires sur Internet. La personne remplissait les champs, appuyait sur un bouton et les données étaient envoyées au responsable. Qu’y a-t-il de si difficile là-dedans ? Mais si vous creusez un peu plus - ajoutez une logique conditionnelle, le chargement de fichiers, le stockage des requêtes dans la base de données, des notifications normales - et une tâche simple se transforme en un projet d'ingénierie pour intégrer un zoo d'extensions.

C'est cette expérience qui nous a poussé à créer notre propre générateur de formulaires au sein de COS WP Woo. Pas seulement un autre plugin pour les formulaires - le monde en a assez vu - mais un module intégré qui résout entièrement le problème. Avec un générateur visuel de glisser-déposer, une logique conditionnelle, un stockage d'applications, des notifications par e-mail et une insertion via un shortcode. Tout en un, pas de dépendances, pas de conflits de versions, pas d'abonnement annuel pour chaque module complémentaire séparément. Et aujourd’hui, je veux vous dire comment cela fonctionne de l’intérieur, pourquoi nous avons pris ces décisions et en quoi notre approche diffère de celle à laquelle tout le monde est habitué.

Mais avant d'entrer dans les détails techniques, soyons honnêtes sur les problèmes des solutions existantes. Pour n’offenser personne, Contact Form 7 a fait un excellent travail pour l’écosystème WordPress et mérite le respect. Mais c’est la compréhension des problèmes qui permet d’évaluer pourquoi une alternative est nécessaire.

Contact Form 7 est un plugin sorti en 2007. Il y a dix-neuf ans. Depuis, il a été téléchargé plus de 340 millions de fois et est utilisé sur des millions de sites. Mais voici le problème : son architecture est restée essentiellement la même. Les formulaires sont décrits à l'aide de modèles de texte avec des balises telles que [text* your-name] et [email* your-email]. Pas d'éditeur visuel. Pas d'aperçu. Vous écrivez le code du formulaire dans le champ de texte, l'enregistrez, accédez à la page et voyez s'il ressemble à ce que vous vouliez ou non. Et ainsi de suite en cercle. Pour un développeur, c'est tolérable. Pour un manager ou un marketeur qui souhaite modifier un formulaire sur un site Web, il s'agit d'un mur. Un mur impénétrable de crochets et de paramètres incompréhensibles.

Et ce n'est que le début. Voulez-vous qu’un champ s’affiche en fonction de la sélection dans un autre ? Définissez les champs conditionnels. Vous souhaitez que les candidatures soient stockées dans une base de données et pas seulement envoyées à la poste ? Mettez Flamingo. Souhaitez-vous que le client puisse joindre un PDF ou une photo ? Définir le téléchargement de fichiers. Voulez-vous des styles normaux? Installez les skins CF7 ou écrivez CSS manuellement. Chacune de ces tâches est un plugin distinct avec un auteur distinct, un cycle de mise à jour distinct et une licence distincte. Sur un projet, j'ai compté sept plugins liés à Contact Form 7. Sept. Et le chef de projet s’est plaint qu’après la mise à jour de WordPress vers la version 6.5, trois formulaires ont cessé de fonctionner car l’un des modules complémentaires était incompatible. Est-ce une histoire familière ?

Bien sûr, il existe des alternatives payantes - WPForms, Gravity Forms, Formidable Forms. Ils résolvent de nombreux problèmes de CF7 : éditeur visuel, logique conditionnelle, stockage d'applications - le tout dans un seul package. Mais ils demandent de l'argent pour cela. WPForms Pro – 199 $/an. Formes gravitationnelles – 259 $. Et c'est pour un site. Si vous avez dix projets, multipliez-les. Et si en même temps vous avez également besoin d'extensions WooCommerce pour le B2B, la recherche, la livraison, la sécurité, le budget pour les plugins commence à paraître indécent. J'ai travaillé avec une entreprise qui payait au total plus de mille cinq cents dollars par an rien que pour les plugins. Et les formulaires étaient loin d’être l’article le plus cher.

Pourquoi créer des formulaires dans un plugin WooCommerce

Pour être honnête, lorsque nous planifiions le module de formulaires pour COS WP Woo, il y a eu des conflits au sein de l'équipe. L’argument contre cela ressemblait à ceci : « Les formulaires sont un univers à part, pourquoi les glisser dans un plugin de commerce électronique ? Et l’argument n’était pas dénué de sens. Les formulaires sont un sujet très complexe, ils ont leurs propres modèles UX, leurs propres exigences de sécurité (CSRF, XSS, validation) et leurs propres nuances de stockage de données. Mais plus je travaillais avec de vraies boutiques WooCommerce, plus c'est devenu clair : les formulaires font partie intégrante d'une boutique en ligne. Pas quelque chose d’extérieur, boulonné sur le côté, mais un élément organique.

Pensez par vous-même. Formulaire de demande CP – Où doit-il mener ? Dans le CRM d'un directeur commercial, lié à WooCommerce. Formulaire de demande de sélection d'un analogue - elle doit connaître le catalogue de produits. Formulaire de rappel – il doit apparaître dans le contexte de la page produit. Formulaire d'enquête de satisfaction - il est lié à la commande. Ce ne sont pas tous des « formulaires abstraits sur le site Web », mais des éléments du processus de trading. Et quand ils vivent dans un plugin séparé, vous perdez le contexte. Le responsable voit la demande dans Flamingo, mais ne voit pas de quelle page elle provient ni quel produit le client consultait. Ou il le voit, mais à travers des béquilles - champs cachés, balises UTM, transmission de paramètres via URL. Tout fonctionne tant que ça marche. Et puis ça casse, et personne ne comprend pourquoi.

Nous avons donc décidé : les formulaires font partie de la plateforme. Pas un addon, pas une intégration, mais un module intégré qui sait tout du contexte WooCommerce. Qui stocke les données dans les mêmes tables personnalisées que les autres modules. Qui envoie des e-mails via le même module SMTP déjà configuré dans le plugin. Qui est contrôlé via la même interface React à laquelle l'administrateur est habitué. Cette décision a déterminé l’architecture de tout ce qui a suivi.

Parlons maintenant de la façon dont cela fonctionne en pratique. Parce que les solutions architecturales sont excellentes, mais autre chose est plus important pour l'administrateur du site : la rapidité avec laquelle il peut créer un formulaire, le publier sur la page et commencer à recevoir des candidatures.

Lorsque vous ouvrez le module Formulaires dans l'administrateur COS WP Woo (chemin : Store - Forms), vous voyez une liste de tous les formulaires. Il s'agit d'un tableau avec les noms, le nombre de champs, le statut et le nombre de candidatures reçues. Tout est simple et clair. Cliquez sur « Créer un formulaire » et vous serez redirigé vers le concepteur plein écran. Et c'est là que le plaisir commence.

Le mode plein écran est une décision consciente. Nous avons longtemps expérimenté différentes approches : un éditeur intégré dans la barre latérale, une fenêtre modale, une page séparée dans la mise en page standard de WordPress. Et nous sommes arrivés à la conclusion que le concepteur de formulaires devait occuper tout l'écran. Pourquoi? Parce que vous construisez un objet visuel. Vous devez voir à quoi ressemblera la forme à l’échelle réelle. Vous avez besoin d'espace pour faire glisser les champs, pour définir les conditions, pour prévisualiser. Le constructeur inséré dans la barre latérale de WordPress, c'est comme peindre une image à travers un trou de serrure. C'est possible, mais pourquoi ?

Canevas plein écran et champs de déplacement

Le concepteur est divisé en trois zones. Sur la gauche se trouve un panneau de types de champs disponibles. Au centre se trouve le canevas du formulaire, où les champs sont situés dans l'ordre dans lequel l'utilisateur les verra. Sur la droite se trouve le panneau de paramètres du champ sélectionné. Cette disposition à trois colonnes est familière à tous ceux qui ont travaillé avec Figma, Canva ou même PowerPoint. Il s'agit d'un modèle intuitif qui ne nécessite aucune formation.

Les types de champs disponibles couvrent presque tous les scénarios que j'ai rencontrés dans des projets réels. Champ de texte - pour le nom, le sujet de l'appel, le commentaire libre. Champ numérique - pour la quantité, le volume, le budget. Email - avec validation automatique du format. Téléphone - avec un masque de saisie afin que le numéro soit reçu dans un format uniforme. Textarea - pour les messages développés. Liste déroulante (Sélectionner) - lorsque vous devez limiter le choix à des options spécifiques : type d'équipement, région de livraison, mode de communication. Cases à cocher pour une sélection multiple : services d'intérêt, caractéristiques souhaitées. Boutons radio - lorsque vous devez sélectionner exactement une option. Date - avec un calendrier pour sélectionner la date de livraison ou de consultation souhaitée. Téléchargement de fichiers - pour les dessins, les spécifications techniques, les photographies. Et même un champ de signature – pour les utilisateurs mobiles qui peuvent signer avec leur doigt directement sur l'écran. Soit dit en passant, cela s'est avéré de manière inattendue être demandé sous la forme de certificats d'acceptation et de demandes de réparations sous garantie.

Chaque champ est un composant React qui est rendu sur le canevas exactement tel qu'un visiteur du site le verra. Pas de « aperçu dans un nouvel onglet » : vous voyez le résultat au fur et à mesure que vous travaillez. Nous avons fait glisser le champ du panneau de gauche sur la toile et il est apparu. Cliquez dessus et les paramètres s'ouvrent à droite : étiquette, espace réservé, obligatoire, largeur (pleine ou moitié pour les mises en page à deux colonnes), valeur par défaut, texte d'info-bulle. Tout cela change en temps réel - nous avons ajusté l'étiquette à droite et elle a été immédiatement mise à jour sur la toile.

Pour implémenter le glisser-déposer, nous utilisons la bibliothèque @hello-pangea/dnd - il s'agit d'un fork de @hello-pangea, qui est lui-même une continuation de react-beautiful-dnd d'Atlassian. Le choix n'est pas aléatoire. Nous avons essayé plusieurs options : react-dnd, dnd-kit, Sortable.js avec un wrapper React. Chacun avait ses avantages, mais @hello-pangea/dnd a gagné sur la base d'une combinaison de facteurs. Il fournit un excellent retour tactile : l'élément « décolle » du panneau, suit le curseur et un espace réservé apparaît sur le canevas, indiquant où ira l'élément. Il fonctionne correctement avec les écrans tactiles, ce qui est important car de plus en plus de personnes gèrent des sites Web à partir de tablettes. Et cela ne nécessite pas d'écrire vos propres algorithmes de collision, qui devraient être configurés manuellement dans dnd-kit.

Mais le concepteur visuel n'est que la partie externe. Sous le capot, chaque formulaire est une structure JSON qui stocke une description de tous les champs, leur ordre, leurs paramètres et leurs règles de validation. Lorsque vous enregistrez le formulaire, ce JSON est enregistré dans la table wpaic_forms. Lorsqu'un visiteur ouvre une page avec un formulaire, le code PHP sur le backend lit le JSON et génère du HTML avec les gestionnaires de balisage, de validation et JavaScript corrects. Cela signifie que le formulaire fonctionne même si la partie React du plugin n'est pas chargée - elle est entièrement côté serveur sur le front-end. Aucun retard de rendu, aucun problème de référencement.

Et ici, je veux aborder un point que de nombreux créateurs de formulaires ignorent. L’aperçu en direct est bien plus qu’une simple commodité. Il s'agit d'une prévention des erreurs. Lorsqu'un manager construit un formulaire en mode texte, comme dans CF7, il ne voit pas le résultat. Il devine. Et puis il s'étonne que le champ « Commentaire » apparaisse avant le champ « Nom », ou que les cases à cocher soient disposées en colonne au lieu d'une ligne, ou encore que sur mobile le formulaire ressemble à une longue feuille. Avec un designer visuel, ces erreurs sont impossibles : vous voyez exactement ce que le client verra. Et cela fait gagner des heures. Je le sais parce que j'ai moi-même passé ces heures à jouer avec les modèles CF7 et à actualiser la page dans le navigateur encore et encore.

Parlons maintenant de ce qui rend les formulaires vraiment puissants : la logique conditionnelle. Soumettez un formulaire de demande de sélection d’huile. Première question : « Type d'équipement » - liste déroulante : Automobiles, Équipements industriels, Hydraulique, Autres. Si le client sélectionne « Voitures », les champs « Marque » et « Modèle » apparaissent. Si vous sélectionnez « Équipement industriel », « Type de mécanisme » et « Conditions de fonctionnement » apparaissent. Si « Autre » est un champ de texte pour une description gratuite. Sans logique conditionnelle, il faudrait afficher tous les champs à la fois, et le formulaire se transformerait en un questionnaire de deux pages, que le client s'enfuirait sans remplir.

Dans Contact Form 7, cela nécessite un plugin de champs conditionnels distinct, qui fonctionne via des hacks CSS et des gestionnaires JavaScript, qui entrent souvent en conflit avec d'autres scripts de la page. Nous avons intégré la logique conditionnelle directement dans le constructeur. Dans les paramètres de chaque champ, il y a une section « Conditions d'affichage ». Il vous suffit de sélectionner : « Afficher ce champ si le champ [Type d’équipement] est [Véhicules].» Ou "Masquer ce champ si le champ [Budget] est inférieur à 10 000." Vous pouvez combiner plusieurs conditions en utilisant « AND » ou « OR ». L'interface pour cela est un générateur de règles visuelles, similaire à celui que nous utilisons pour les champs personnalisés dans le module CF. Pas de code, pas de formules de texte.

La logique conditionnelle est gérée côté client via JavaScript, qui est automatiquement généré à partir de la description du formulaire JSON. Cela signifie que les champs apparaissent et disparaissent instantanément, sans recharger la page, sans requêtes AJAX. L'utilisateur a sélectionné une option dans la liste et les champs obligatoires sont apparus en douceur. J'en ai choisi un autre - les précédents ont disparu, de nouveaux sont apparus. Cela crée la sensation d'une interface interactive plutôt que d'un formulaire HTML statique. Et surtout, les champs masqués ne participent pas à la validation : si un champ est masqué par une condition, il ne sera pas considéré comme obligatoire, même s'il est marqué comme obligatoire. C’est un point subtil sur lequel de nombreuses implémentations butent.

Je me souviens d'un projet où nous utilisions WPForms avec une logique conditionnelle, et nous avons rencontré un bug : un champ obligatoire masqué bloquait la soumission du formulaire car sa validation était déclenchée même lorsque le champ était invisible. Le client n'a pas pu soumettre le formulaire et est parti. Nous avons perdu des applications jusqu'à ce que nous comprenions et écrivions une béquille en JavaScript. C’est une de ces leçons qui vous restent longtemps. Par conséquent, dans notre implémentation, les champs cachés sont exclus de la validation au niveau architectural - ce n'est pas une correction de bug, mais une règle fondamentale.

Applications - non pas vers un courrier électronique, mais vers une base de données

Venons-en maintenant à un sujet qui, à mon avis, est le principal point faible de Contact Form 7 et des solutions gratuites similaires. Où vont les candidatures ? Dans CF7, la réponse est simple : par e-mail. La candidature est arrivée et j'ai envoyé un email au responsable. Point. Pas d'e-mail - pas de candidature. Et les serveurs de messagerie ont tendance à perdre des lettres. Les filtres anti-spam ont tendance à bloquer les notifications de WordPress, surtout si le serveur n'est pas parfaitement configuré : pas d'enregistrement SPF, pas de DKIM, pas de DMARC. Je connais personnellement trois cas où une entreprise a perdu des applications pendant des semaines parce que les notifications du formulaire de contact 7 se sont retrouvées dans le spam sur le serveur de messagerie. Et personne ne le savait jusqu’à ce que les clients commencent à appeler pour se plaindre : « J’ai laissé une demande, pourquoi personne n’a rappelé ?

Flamingo résout ce problème : il stocke les tickets dans une base de données WordPress. Mais il s’agit d’un plugin distinct, avec sa propre interface, sa propre logique de stockage et ses propres limites. Les applications sont stockées sous forme de publications personnalisées (post_type), ce qui crée une charge sur la table wp_posts, déjà surchargée sur les grands sites. Sur l'un de nos projets avec 16 000 produits, la table wp_postmeta pèse 937 mégaoctets - et y ajouter des requêtes à partir de formulaires serait une folie.

Nous avons emprunté un chemin différent. Toutes les applications sont stockées dans une table personnalisée wpaic_form_entries. Il s'agit d'un tableau dédié avec une structure optimale : ID d'enregistrement, ID de formulaire, données de la demande au format JSON, date de création, statut (nouveau, lu, en cours, fermé), adresse IP de l'expéditeur, User-Agent, ID utilisateur (si autorisé). Une table sur mesure n'est pas un caprice, c'est une décision architecturale consciente. Il n'obstrue pas wp_posts, dispose des index appropriés pour une recherche et un filtrage rapides et évolue de manière linéaire : dix mille soumissions sont aussi rapides que dix.

Dans l'interface d'administration, les demandes sont affichées dans un tableau pratique avec la possibilité de filtrer par formulaire, statut, date et recherche en texte intégral. Vous pouvez retrouver toutes les candidatures contenant le mot « hydraulique », ou toutes les candidatures de la semaine dernière, ou encore toutes les candidatures non lues pour un formulaire spécifique. Vous pouvez ouvrir chaque application, voir toutes les données dans un beau format, télécharger les fichiers joints, modifier le statut et ajouter un commentaire interne.

Et bien sûr, exporter. Les formulaires sans export sont comme un CRM sans rapports. Cela ne sert à rien. Nous prenons en charge l'exportation au format CSV avec sélection de champs, filtrage par date et statut. Nous avons téléchargé le CSV, l'avons ouvert dans Excel ou Google Sheets et analysé quels produits sont demandés le plus souvent, de quelles régions proviennent les candidatures, quels formulaires se convertissent le mieux. Ce sont les données que vous perdez lorsque les applications ne sont disponibles que par courrier.

Il existe une autre nuance dont on parle rarement. Lorsque les applications sont stockées dans une base de données, vous disposez d'un audit. Vous savez exactement combien de candidatures ont été reçues. Pas « approximativement », pas « à en juger par le courrier », mais exactement. Le gestionnaire ne peut pas dire « il n'y a pas eu de candidature » - cela est enregistré dans le système avec la date, l'heure, l'adresse IP et toutes les données. Ceci est particulièrement important pour les entreprises B2B, où chaque application peut coûter des centaines de milliers de roubles. Perdre une telle application à cause d'un filtre anti-spam n'est pas seulement un inconvénient, c'est une perte directe.

Mais soyons honnêtes : des notifications par e-mail sont également nécessaires. Tous les gestionnaires ne se connecteront pas à l'administrateur WordPress toutes les heures pour rechercher de nouvelles applications. Nous avons donc mis en place un double système : l'application est toujours enregistrée dans la base de données (c'est une garantie), et en même temps une notification par email est envoyée (c'est l'efficacité). De plus, l'e-mail est envoyé via le module SMTP intégré COS WP Woo, que vous configurez une fois dans la section Paramètres de messagerie. Pas de plugins SMTP séparés, pas de WP Mail SMTP pour 49 $/an. Un module SMTP pour tout : notifications de commandes, notifications d'applications, notifications de sécurité.

Les notifications par e-mail sont personnalisables. Pour chaque formulaire, vous définissez : à qui envoyer la notification au responsable (plusieurs adresses possibles), quel modèle utiliser, quelles données inclure. Et séparément - une notification au client : "Merci, votre candidature a été acceptée, nous vous contacterons dans les 24 heures." La notification client est envoyée à l'e-mail spécifié dans le champ de type « Email » - le plugin détermine automatiquement quel champ contient l'adresse du destinataire. Modèles d'e-mails – HTML avec espaces réservés : {{field_name}}, {{form_title}}, {{submission_date}}. Vous pouvez personnaliser l'apparence, ajouter un logo d'entreprise et des informations de contact. Nous n'avons pas écrit un moteur de modèles universel, mais un outil cible pour une tâche spécifique - il fonctionne donc de manière prévisible et ne se casse pas en raison de conceptions non standard.

Je vais vous parler d'une autre solution technique qui peut paraître anecdotique, mais en pratique, elle sauve les nerfs. Téléchargement de fichiers. Dans Contact Form 7 avec le plugin File Upload, les fichiers sont joints aux e-mails sous forme de pièces jointes. Cela fonctionne jusqu'à ce que quelqu'un envoie un fichier de 25 Mo que votre serveur de messagerie ne laisse pas passer. Ou de 50 mégaoctets - alors PHP plantera avec une erreur de limite de mémoire. Chez nous, les fichiers sont téléchargés dans un répertoire protégé sur le serveur (hors accès public afin que les robots ne téléchargent pas les documents clients) et sont liés au dossier de candidature par ID. Vous recevrez un lien de téléchargement dans votre e-mail, qui ne fonctionne que pour les administrateurs autorisés. Il est plus sûr, plus fiable et ne dépend pas des restrictions du serveur de messagerie. Le client peut joindre un dessin de 50 mégaoctets - et le gestionnaire le recevra, c'est garanti.

Maintenant - codes courts. Il semblerait, de quoi y a-t-il à discuter ici ? [wpaic_form id="42"] - et le formulaire est apparu sur la page. Mais le diable, comme toujours, se cache dans les détails. Un shortcode peut être inséré dans une publication, une page, un widget, un plugin pop-up, un modèle de thème, voire une description de produit WooCommerce. Le formulaire s'adapte au conteneur - si le conteneur est étroit (barre latérale ou popup), le formulaire passe en mode colonne unique. S’ils sont larges (page plein écran), les champs définis sur demi-largeur apparaîtront sur deux colonnes. Il s’agit d’un comportement réactif qui fonctionne immédiatement. Vous n'avez pas à vous soucier des requêtes multimédias CSS : le concepteur s'en charge.

Vous savez ce qui m'a toujours ennuyé dans l'approche de CF7 en matière de shortcodes ? Là, le shortcode est le seul moyen de l'insérer. Pas de bloc Gutenberg, pas de widget Elementor. Shortcode et c'est tout. En 2026. Nous avons également commencé avec un shortcode - c'est le mécanisme WordPress le plus universel qui fonctionne partout. Mais notre shortcode est intelligent : il accepte des paramètres pour personnaliser l’apparence. Vous pouvez définir un thème (clair, foncé, transparent), vous pouvez masquer le titre du formulaire, vous pouvez définir un texte personnalisé pour le bouton de soumission. Et tout cela sans une seule ligne de CSS – via les attributs du shortcode.

Comparaison équitable : nous, WPForms, Gravity Forms et CF7

J'ai promis une comparaison honnête, alors faisons-le sans clins d'œil marketing. Chaque solution a ses propres atouts, et je ne vais pas prétendre que notre constructeur est parfait.

Formulaire de contact 7 - gratuit, léger et éprouvé. Si vous avez besoin d'un formulaire simple, sans logique conditionnelle et sans stockage d'applications, CF7 peut le gérer. Tous les développeurs WordPress le savent, des milliers de guides ont été rédigés à cet effet. Mais dès que la tâche devient un peu plus compliquée « nom-email-message », le zoo des plugins commence. Et le coût de ce zoo en matière de prise en charge et de débogage des conflits dépasse souvent le coût de toute solution payante.

WPForms est un excellent plugin avec un excellent éditeur visuel. Leur glisser-déposer est l’un des meilleurs du marché. Logique conditionnelle, stockage des applications, intégration avec CRM, tout y est. Mais WPForms est un plugin distinct qui résout uniquement le problème des formulaires. Il ne connaît pas votre catalogue WooCommerce, n'est pas intégré à votre système d'expédition et n'utilise pas votre module SMTP. Il existe dans sa propre bulle. Et cela coûte 199 $ par an pour la version Pro, nécessaire à la logique conditionnelle et au téléchargement de fichiers. Sur 5 ans – mille dollars rien que pour les formulaires.

Gravity Forms est peut-être le générateur de formulaires le plus puissant pour WordPress. Formulaires en plusieurs étapes, calculs, intégrations avec les systèmes de paiement, Webhooks, un incroyable écosystème d'addons. Mais cette puissance a un prix, à la fois en dollars (259 par an pour une licence Elite) et en complexité. Gravity Forms peut tout faire, mais tout configurer demande du temps et de l'expertise. Pour les formulaires de commentaires simples, c'est comme tirer sur des moineaux avec un canon.

Notre générateur de formulaires dans COS WP Woo est le juste milieu. Il n’est pas destiné à remplacer Gravity Forms dans des scénarios comportant des calculs complexes ou des enquêtes en plusieurs étapes comportant des centaines de questions. Mais il couvre à cent pour cent les besoins réels d’une boutique WooCommerce. Formulaires de commentaires, demandes de sélection, demandes de CP, enquêtes de satisfaction, questionnaires d'inscription B2B - tout cela est construit en quelques minutes dans un constructeur visuel. De plus, les formulaires font partie d’une plateforme unique. Ils utilisent SMTP commun, sont stockés dans des tables personnalisées optimisées et sont gérés à partir de la même interface que tous les autres modules. Et ils ne coûtent pas d’argent supplémentaire – ils sont inclus dans la licence COS WP Woo.

Laissez-moi vous donner un exemple concret tiré de la pratique. Le client est un distributeur d'huiles industrielles. Il lui faut trois formulaires. Le premier est « Demander un prix » sur les pages produits : nom, société, téléphone, email, liste déroulante « Volume du lot » (de 20 à 200 litres, de 200 à 1000, à partir de 1000), commentaire. La seconde est « Sélection d'un analogue » sur la page du catalogue : type d'équipement (logique conditionnelle pour les champs supplémentaires), huile actuelle (texte), caractéristiques souhaitées (cases à cocher), téléchargement de fichier (TOR ou passeport équipement). Le troisième est « Devenir partenaire » sur la page « Coopération » : coordonnées de l'entreprise, NIF (avec validation de longueur), région, volume d'achats, téléchargement des documents constitutifs.

Avec Contact Form 7, ce projet aurait nécessité : CF7 + Champs conditionnels + Flamingo + Téléchargement de fichiers + style = 5 plugins et au moins 3 heures de personnalisation (y compris l'édition CSS). Avec le plugin WPForms Pro - 1, 199 $ par an et environ une heure d'installation. Avec notre builder - 0 plugin supplémentaire, 0 coût supplémentaire et environ 40 minutes dans le builder visuel. De plus, les trois formulaires sont immédiatement intégrés à SMTP, les applications sont stockées dans une seule base de données avec recherche et exportation, et le gestionnaire les voit dans la même interface où il gère tout le reste.

Je souhaite parler d'un autre aspect qui est souvent négligé lors de la comparaison. Performance. Contact Form 7 charge ses styles et scripts sur chaque page du site, même s'il n'y a aucun formulaire dessus. Il s'agit d'un problème connu qui peut être résolu soit par des plugins supplémentaires (Asset CleanUp, Perfmatters), soit en éditant manuellement le code. WPForms charge uniquement les ressources sur les pages de formulaire, mais son ensemble JavaScript pèse entre 60 et 80 Ko une fois réduit. Nos formulaires sont rendus sur le serveur au format HTML pur avec un minimum de JavaScript pour la logique conditionnelle et la validation. Formulaires CSS - 5 Ko, JavaScript - 8 Ko. Et ils ne se chargent que sur les pages où le shortcode du formulaire est réellement présent. Pour un magasin avec 16 000 pages de produits, la différence est perceptible - chaque kilo-octet supplémentaire de CSS et JS est multiplié par des milliers de pages dans le cache, en analysant le temps dans le navigateur, par Core Web Vitals.

Je voudrais également évoquer la sécurité. Les formulaires sont un point d’entrée pour les attaquants. Injections SQL via les champs de saisie, XSS via les champs de texte, attaques CSRF via la substitution de formulaires, robots spammeurs qui inondent des milliers d'applications par minute. Nous traitons toutes les données via les fonctions de désinfection de WordPress : sanitize_text_field(), sanitize_email(), wp_kses_post() pour les champs HTML. Chaque formulaire est protégé par un jeton occasionnel. Les fichiers téléchargés sont vérifiés par type et extension MIME - vous ne pourrez pas télécharger un fichier PHP même si vous le renommez en .jpg. Et si le module de sécurité est activé dans COS WP Woo, WAF vérifie en outre toutes les données entrantes pour détecter les modèles d'injections SQL et d'attaques XSS. Il s'agit d'une intégration qui n'est pas possible lorsque les formulaires et la sécurité sont des plugins différents d'auteurs différents.

Et la dernière chose que je veux dire sur le dispositif technique. L'architecture du module Forms suit le même schéma que tous les autres modules COS WP Woo : service PHP (FormService) pour la logique métier, contrôleur REST (FormController) pour l'API, page React (FormBuilder) pour l'interface. Le service est enregistré dans class-plugin.php, les points de terminaison fonctionnent via l'espace de noms wpaic/v1, les données sont stockées dans des tables personnalisées. Si vous connaissez l’architecture de notre plugin, vous savez déjà comment fonctionnent les formulaires. Sinon, les formulaires sont un excellent point d'entrée car ils affichent le modèle dans sa forme la plus pure : de la description JSON du formulaire via l'API REST jusqu'au rendu sur le front-end.

Quand notre constructeur ne suffit pas

Je ne veux pas terminer cet article sur la note marketing de « notre solution est la meilleure ». Ce ne serait pas juste. Il existe des scénarios pour lesquels notre générateur de formulaires n'est pas le meilleur choix.

Si vous avez besoin de formulaires multi-étapes avec des dizaines d'étapes, une barre de progression et une sauvegarde des résultats intermédiaires, jetez un œil à Gravity Forms. Ils l’ont mis en œuvre de manière mature et fiable. Si vous avez besoin d'une intégration prête à l'emploi avec un CRM comme HubSpot, Salesforce ou AmoCRM, WPForms et Gravity Forms ont des modules complémentaires prêts à l'emploi, mais nous devrons utiliser des Webhooks ou écrire une intégration personnalisée. Si vous avez besoin de formulaires de paiement avec intégration Stripe ou PayPal directement dans le formulaire, ce n'est pas notre scénario ; pour cela, nous disposons d'une caisse WooCommerce à part entière avec un module de paiement. Si vous créez un questionnaire complexe de 100 questions avec branchement et notation, vous avez besoin d'un outil spécialisé comme Typeform ou Google Forms.

Mais si vous êtes le propriétaire ou l'administrateur d'une boutique WooCommerce et que vous avez besoin de formulaires de travail pour les commentaires, les tickets, les demandes CP, les enquêtes avec logique conditionnelle, les téléchargements de fichiers et le stockage de base de données - notre générateur de formulaires le fera plus rapidement, plus fiable et moins cher que n'importe quelle combinaison de modules complémentaires CF7 + ou un abonnement annuel à WPForms Pro.

Et savez-vous quelle a été pour moi la preuve la plus convaincante que nous sommes sur la bonne voie ? Pas de mesures techniques, pas de nombre de types de champs, pas de tableaux de comparaison avec les concurrents. Et ce moment où le responsable d'un projet client - une personne qui avait peur de "entrer dans le code" toute sa vie - a rédigé en vingt minutes un formulaire de candidature avec une logique conditionnelle, l'a inséré sur trois pages via un shortcode, et le lendemain est arrivé avec la question : "Puis-je créer un autre formulaire pour une enquête ? Je comprends déjà à peu près comment." Il s'agit d'un véritable indicateur de la qualité de l'outil - lorsqu'une personne n'a pas besoin d'instructions, n'a pas besoin d'un développeur et n'a pas besoin de cinq plugins pour un formulaire.

Essayez COS WP Woo et créez votre premier formulaire en cinq minutes. Le module Formulaires est disponible dans la section Boutique - Formulaires. Glissez et déposez des champs, définissez des conditions, insérez un shortcode sur la page - et commencez à recevoir des candidatures dont l'accès au gestionnaire est garanti.