Les formulaires qui déclarent des contraintes HTML natives produisent moins de rejets de validation côté serveur par soumission que les formulaires validés uniquement en JavaScript personnalisé

Hypothèse

La validation côté serveur est obligatoire ; la validation côté client existe pour que la plupart des soumissions ne la déclenchent jamais. Il existe deux façons de fournir le côté client : les attributs de contrainte natifs sur les contrôles (required, type, pattern, min, max, maxlength), que le navigateur vérifie avant une soumission interactive, ou un script personnalisé qui inspecte les valeurs et bloque l'événement submit. Le guide de MDN sur la validation de contraintes décrit le mécanisme natif et ses limites : un attribut novalidate sur le formulaire désactive la validation interactive, et l'appel de la méthode submit() du formulaire envoie les données au serveur même si elles ne satisfont pas les contraintes. Un schéma courant consiste à écrire une validation personnalisée pour le style et les messages, en abandonnant les attributs natifs au passage. L'hypothèse est que les formulaires dont les attributs natifs reflètent les règles du serveur produisent moins de rejets côté serveur par soumission que les formulaires validés uniquement par script, et que la différence provient surtout des sessions où le script ne s'est pas exécuté : il n'a pas pu se charger, il a levé une erreur avant d'attacher ses gestionnaires, ou il a manqué les chemins de remplissage automatique et de collage.

Prédiction

Dans une comparaison A/B du même formulaire avec et sans attributs de contrainte natifs, les deux variantes conservant le même script personnalisé et les mêmes règles serveur, la variante dotée d'attributs natifs présente un taux de rejets de validation côté serveur par soumission plus bas. L'écart se concentre dans les sessions où le script a rencontré une erreur ou où le marqueur de disponibilité du script est absent, et il est proche de zéro là où le script s'est exécuté ; les catégories de rejets qui diminuent sont celles que les attributs natifs peuvent exprimer (champs obligatoires manquants, adresse e-mail mal formée, nombres hors plage), pas les règles inter-champs. Si les taux de rejet sont égaux, ou si l'écart ne se concentre pas dans les sessions d'échec du script, l'hypothèse est fausse.

Test proposé

1. Choisir un formulaire public recevant quelques milliers de soumissions par mois et un serveur qui renvoie des erreurs de validation structurées par champ.
2. Construire une variante A avec des attributs natifs correspondant champ par champ aux règles du serveur, et une variante B avec ces attributs retirés ; garder le script, la mise en page et les messages identiques. Répartir les visiteurs par un hachage stable.
3. Ajouter un champ caché que le script définit lorsque ses gestionnaires s'attachent, afin que le serveur puisse déterminer si le script s'est exécuté ; journaliser les erreurs de script avec la variante.
4. Pendant quatre semaines, enregistrer par soumission : la variante, le marqueur d'exécution du script, le rejet (oui ou non) et les champs rejetés avec leurs catégories de règles.
5. Comparer les taux de rejet par variante globalement et en les répartissant selon le marqueur ; rapporter les effectifs et les intervalles, et lister les catégories de règles qui diffèrent.

Statut

Aucun résultat n'est avancé. Si le script est fiable et que les navigateurs du public échouent rarement à l'exécuter, la différence pourrait être trop faible pour être mesurée en quatre semaines ; ce résultat indiquerait en lui-même l'apport de la couche native pour ce public.