Un cabinet d’expertise comptable, un caviste en ligne, et une école de formation : trois clients de Kaolin, trois besoins de formulaire front en apparence similaires (contact, inscription, demande de devis), mais qui ont chacun justifié un choix technique différent. Le bloc formulaire REST fait maison, souvent la première tentation d’un développeur qui maîtrise déjà l’API de blocs, a déjà été détaillé en profondeur ailleurs sur WP Moderne. Cet article compare les trois approches réellement disponibles, sans revenir sur le détail d’implémentation du premier.
Option 1 : bloc REST fait maison
Un bloc dynamique avec un formulaire HTML natif, soumis via apiFetch vers un point de terminaison REST personnalisé, protégé par nonce. Cette approche donne un contrôle total sur le balisage, les styles, et le comportement de validation, sans dépendance à un plugin tiers. Sa limite apparaît dès que le formulaire doit évoluer souvent : chaque nouveau champ, chaque règle conditionnelle (« afficher ce champ seulement si telle case est cochée ») demande du développement sur mesure, facturé au temps passé.
Option 2 : Gravity Forms intégré en bloc
Gravity Forms fournit son propre bloc d’insertion de formulaire dans l’éditeur, avec un constructeur de formulaire complet côté administration : champs conditionnels, intégrations tierces (paiement, CRM), notifications par e-mail configurables sans code. Pour l’école de formation, dont l’équipe interne modifie régulièrement ses formulaires d’inscription sans intervention d’un développeur, cette autonomie a justifié le coût de la licence.
La contrepartie : le style du formulaire reste partiellement contraint par les classes CSS générées par le plugin, et toute personnalisation profonde du comportement (une logique métier spécifique non couverte par les options du constructeur) nécessite ses propres hooks PHP et JavaScript, avec une courbe d’apprentissage propre à l’écosystème du plugin.
Option 3 : bloc hybride avec validation Interactivity API
Pour le caviste en ligne, dont le formulaire de réservation de dégustation nécessitait une validation en temps réel complexe (disponibilité de créneaux, quantité de bouteilles en stock) sans réécrire un système de formulaire complet, l’équipe a construit un bloc hybride : structure HTML native comme dans l’option 1, mais validation et interactions gérées par des directives data-wp-* de l’Interactivity API plutôt que par du JavaScript impératif classique.
<form
data-wp-interactive="brumaire/reservation"
data-wp-context='{ "quantite": 1, "erreur": "" }'
data-wp-on--submit="actions.validerEtEnvoyer"
>
<input
type="number"
data-wp-bind--value="context.quantite"
data-wp-on--input="actions.mettreAJourQuantite"
/>
<span data-wp-bind--hidden="!context.erreur" data-wp-text="context.erreur"></span>
</form>Cette approche offre l’avantage de rester légère et proche du HTML natif tout en gérant une interactivité riche, mais elle exige une équipe à l’aise avec un modèle de programmation encore relativement récent, et un budget de maintenance suffisant pour suivre son évolution.
Tableau comparatif
| Critère | REST fait maison | Gravity Forms | Hybride Interactivity API |
|---|---|---|---|
| Autonomie de l’équipe cliente | Faible, dépend du développeur | Forte, constructeur visuel | Faible, code sur mesure |
| Coût récurrent | Aucun | Licence annuelle | Aucun |
| Logique conditionnelle riche | À développer entièrement | Native, sans code | À développer, mais léger |
| Contrôle total du style | Total | Partiel | Total |
Verdict argumenté
Aucune des trois options ne l’emporte dans l’absolu. Le bloc REST fait maison convient à un formulaire simple, stable dans le temps, sur un projet sans budget de licence récurrente. Gravity Forms devient rentable dès que l’équipe cliente doit elle-même modifier les formulaires sans passer par un développeur, ou dès que la logique conditionnelle dépasse ce qu’il est raisonnable de coder à la main. Le bloc hybride avec Interactivity API se justifie uniquement quand l’interactivité requise est trop riche pour un formulaire natif mais que le projet ne veut ni dépendance à un plugin de formulaire, ni JavaScript impératif classique, et qu’un budget de maintenance suit dans la durée.
Le bon formulaire n’est pas le plus élégant techniquement, c’est celui que l’équipe qui le maintiendra dans deux ans saura encore faire évoluer.
Notre verdict
Sur ces trois projets, le choix s’est fait moins sur la préférence technique de l’équipe que sur qui, dans deux ans, devra modifier le formulaire : un développeur facturé à l’heure, une équipe interne autonome, ou personne du tout si le formulaire est amené à rester figé.
