Le traitement d’un formulaire HTML dans un framework moderne ne se résume plus à intercepter onSubmit et sérialiser des champs. React 19, Angular v22 et Vue 3 ont chacun redéfini la relation entre le <form> natif et la couche réactive. Le mot-clé this form, qu’il soit implicite ou explicite, renvoie à la façon dont chaque framework expose le nœud DOM du formulaire, ses données et son état de validation au code applicatif.
Server Actions React : le formulaire HTML redevient natif
React 19 a introduit un changement d’architecture majeur pour les formulaires. L’attribut action d’un <form> accepte désormais une fonction serveur directement, sans route d’API intermédiaire. Concrètement, un formulaire peut s’envoyer avant même que le JavaScript client ait fini de se charger.
Ce mécanisme, appelé Server Actions dans React et Next.js, réhabilite le comportement HTML natif du formulaire. Le navigateur poste les données via un POST classique, puis React hydrate la réponse. La référence au formulaire (ce que this.form représentait en JavaScript vanilla) est gérée automatiquement par le runtime : le développeur ne manipule plus event.target ni FormData manuellement dans la majorité des cas.
L’intérêt est double. Les formulaires de login, de contact ou de mutation fonctionnent en progressive enhancement pur. Et la surface de code côté client diminue, puisque la logique de validation et de persistance vit sur le serveur.
En revanche, pour les formulaires complexes avec validation en temps réel champ par champ, les hooks useActionState et useFormStatus prennent le relais. Nous recommandons de réserver les Server Actions aux formulaires dont le feedback instantané n’est pas critique, et de garder une gestion côté client pour les parcours interactifs (wizard multi-étapes, auto-complétion, dépendances entre champs).
Angular Signal Forms : FormGroup et FormControl remplacés par des signaux
Angular v22, sorti en août 2026, a stabilisé une nouvelle API de formulaires baptisée Signal Forms. Elle rompt avec le modèle historique des Reactive Forms fondé sur FormGroup, FormControl et FormArray.
Le principe : chaque champ, son état dirty/touched, ses erreurs de validation et sa validité globale deviennent des signaux. Là où les Reactive Forms exposaient un observable RxJS sur valueChanges, les Signal Forms exposent un signal granulaire, lisible sans souscription explicite.
Ce que ça change pour la référence au formulaire
Dans l’ancien modèle, accéder à l’état du formulaire passait par l’injection d’un FormGroup dans le composant, puis par des appels comme this.form.get('email')?.value. Avec les Signal Forms, la syntaxe devient déclarative et le template Angular consomme directement le signal :
- La validation se rapproche du modèle de données : un signal d’erreur est recalculé automatiquement quand la valeur change, sans pipe
asyncnisubscribe. - La compatibilité avec les Reactive Forms existants est maintenue, ce qui permet une migration progressive sur les projets déjà en production.
- Le binding entre le DOM et le modèle ne dépend plus de directives spécifiques comme
formControlName; le signal est la source unique de vérité.
Pour les équipes Angular, cette transition représente une simplification notable du code lié aux formulaires. Nous observons que les projets qui adoptent les Signal Forms réduisent la quantité de boilerplate dans les composants de saisie, tout en gagnant en lisibilité dans les templates.
Vue 3 et v-model : le formulaire piloté par la réactivité fine
Vue n’a pas opéré de rupture équivalente aux Server Actions ou aux Signal Forms, mais son système de formulaires repose sur une mécanique de réactivité fine qui mérite un examen attentif.
Le v-model de Vue 3 fonctionne comme un two-way binding entre le champ HTML et une ref ou une propriété reactive. La référence au formulaire en tant que nœud DOM reste accessible via un template ref (ref="formRef"), mais dans la pratique, la plupart des développeurs Vue ne manipulent jamais le DOM du formulaire directement.
La validation s’appuie sur des bibliothèques comme VeeValidate ou FormKit, qui encapsulent l’état du formulaire dans un store réactif. Le concept de this.form au sens DOM disparaît au profit d’un objet réactif qui porte les valeurs, les erreurs et les métadonnées de soumission.
Quand accéder au nœud DOM reste pertinent
Certains cas exigent encore une référence directe au <form> natif : soumission programmatique via formRef.value.submit(), intégration de paiement tiers qui injecte des iframes dans le formulaire, ou accessibilité avec reportValidity(). Dans ces situations, le template ref Vue donne accès au nœud DOM réel, mais ce pattern reste marginal dans les applications Vue bien structurées.
Formulaire HTML natif ou abstraction framework : critères de choix
Le choix entre un formulaire géré nativement par le navigateur et une couche d’abstraction dépend de trois variables concrètes.
- Le besoin de progressive enhancement : si le formulaire doit fonctionner sans JavaScript (SEO, accessibilité, conformité), les Server Actions React ou un
<form>Vue avec action serveur classique sont pertinents. - La complexité de la validation : un formulaire avec dépendances conditionnelles entre champs, validation asynchrone ou état partagé entre composants justifie une abstraction (Signal Forms Angular, VeeValidate Vue, React Hook Form).
- La taille de l’équipe et la convention de code : Angular impose une structure ; React laisse le choix ; Vue se situe entre les deux. Le framework le moins coûteux est celui que l’équipe maîtrise déjà.
Un formulaire de contact à quatre champs ne justifie pas la même architecture qu’un parcours de souscription bancaire à vingt étapes. Adapter la couche de gestion du formulaire au niveau de complexité réel du cas d’usage reste la seule règle qui traverse les trois frameworks sans exception.
La tendance de fond est claire : React, Angular et Vue convergent vers un modèle où le formulaire HTML natif retrouve son rôle de transport, tandis que la réactivité (signaux, refs, Server Actions) gère l’état applicatif. Comprendre où se situe la frontière entre le DOM et le framework, c’est ce qui sépare un formulaire fonctionnel d’un formulaire maintenable.
