Quelqu'un envoie votre formulaire avec une adresse e-mail invalide. Votre formulaire l'accepte. L'e-mail de bienvenue revient en erreur. La personne n'a plus jamais de nouvelles de vous. Une autre envoie le formulaire avec des champs obligatoires vides. Il passe quand même. Votre équipe se retrouve avec des données incomplètes. Ces deux échecs viennent d'une validation absente ou mal faite.
La validation consiste à vérifier que les données d'un formulaire sont valides avant de les accepter. Elle se fait à deux endroits : dans le navigateur et sur le serveur. Les deux comptent. Cet article explique comment fonctionne la validation, pourquoi il faut les deux et quelles sont les erreurs courantes.
Qu'est-ce que la validation ?
La validation vérifie que les données d'un formulaire respectent vos exigences. Les champs obligatoires ont une valeur. Les champs e-mail contiennent un @. Les champs de téléphone ne contiennent que des chiffres. Les fichiers envoyés respectent la limite de taille.
Sans validation, de mauvaises données entrent dans votre système. Votre serveur plante. Votre service d'e-mail rejette des messages. Vous perdez du temps à nettoyer des données sales.
La validation se fait à deux endroits : côté client (dans le navigateur, avant l'envoi) et côté serveur (sur votre serveur, après l'envoi). Les deux sont nécessaires.
Validation côté client
Le navigateur peut vérifier les données avant de les envoyer. Le HTML a des attributs de validation intégrés. JavaScript peut aussi valider.
Validation HTML
<input type="email" required> vérifie que le champ a une valeur et ressemble à un e-mail. Le navigateur affiche un message d'erreur si l'utilisateur tente d'envoyer un formulaire invalide.
Les attributs de validation HTML comprennent required pour exiger une valeur, min/max pour garder les nombres dans une plage, minlength/maxlength pour imposer un nombre de caractères, pattern pour correspondre à une expression régulière, et type pour valider le type du champ lui-même. Par exemple, type="email" vérifie le format tandis que type="number" refuse les saisies non numériques.
La validation HTML fonctionne tout de suite, sans JavaScript, et donne de bons messages d'erreur par le navigateur, avec des claviers mobiles qui s'adaptent au type de champ. Ses inconvénients : les messages du navigateur sont génériques et parfois peu clairs, on ne peut pas les personnaliser sans JavaScript, et chaque navigateur affiche des messages différents.
Validation JavaScript
Pour plus de contrôle, validez avec JavaScript en utilisant function validateEmail(email) { const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/; return regex.test(email); } et form.addEventListener('submit', (e) => { if (!validateEmail(input.value)) { e.preventDefault(); showError('Please enter a valid email'); } });. La validation JavaScript permet d'écrire vos propres règles, d'afficher des messages d'erreur personnalisés et de valider les champs pendant la saisie, en temps réel. Inconvénients : elle exige JavaScript (peu fiable pour la sécurité), demande plus de code à maintenir et peut afficher des erreurs avant que l'utilisateur ait fini d'écrire si vous validez à chaque frappe.
Validation côté serveur
Une fois le formulaire envoyé, le serveur vérifie à nouveau les données. C'est là que la vraie sécurité se joue.
Ne faites jamais confiance à la validation côté client. Quelqu'un peut désactiver JavaScript. Quelqu'un peut intercepter la requête et modifier les données. Quelqu'un peut utiliser curl ou un outil pour envoyer de mauvaises données sans passer par votre formulaire.
La validation côté serveur est votre seule protection. Elle n'est pas facultative.
Quand le serveur reçoit l'envoi, vérifiez que les champs obligatoires sont présents, validez le format des e-mails, des numéros de téléphone et des URL, contrôlez que les nombres sont dans les plages attendues, vérifiez que les fichiers ont le bon type et la bonne taille, assurez-vous que les données ne sont pas trop longues et désinfectez-les pour éviter les attaques par injection. Si la validation échoue, renvoyez une réponse d'erreur : le formulaire ne doit pas être traité et l'utilisateur doit savoir ce qui ne va pas. La validation côté serveur est plus lente car l'utilisateur doit attendre une réponse, mais elle est fiable et sûre : faites-la toujours.
Quand utiliser chaque type de validation
La validation côté client sert à l'expérience utilisateur. Elle prévient tout de suite en cas de problème. L'utilisateur n'a pas besoin d'envoyer le formulaire pour découvrir qu'un e-mail est invalide.
La validation côté serveur sert à l'intégrité des données et à la sécurité. Elle garantit que de mauvaises données n'entrent jamais dans votre système.
Utilisez les deux. Le côté client pour la rapidité et le retour immédiat. Le côté serveur pour la sûreté et la sécurité.
Erreurs courantes de validation
Ne faire que la validation côté client
Quelqu'un désactive JavaScript et votre validation disparaît. Quelqu'un utilise curl pour envoyer de mauvaises données en POST et votre validation ne s'exécute jamais. Vous vous retrouvez avec des déchets dans votre base de données.
Validez toujours sur le serveur. Le côté client est un plus.
Valider de façon trop stricte
Votre validation d'e-mail est si stricte que de vraies adresses échouent. Votre validation de téléphone n'accepte que le format américain et rejette les numéros internationaux. Votre champ de nom refuse les tirets, les apostrophes et d'autres caractères valides.
Testez votre validation avec des données réelles. Demandez à des utilisateurs d'autres pays de tester. Rendez vos règles aussi souples que possible tout en repérant les mauvaises données.
Ne pas afficher de messages d'erreur clairs
« Saisie invalide. » Qu'est-ce qui est invalide ? Quel champ ? Que doit faire la personne ?
Les messages d'erreur doivent être précis : « L'e-mail doit contenir entre 5 et 254 caractères. » « Le téléphone doit contenir 10 chiffres. » « Le mot de passe doit contenir au moins un chiffre. »
Affichez l'erreur à côté du champ concerné. Ne la cachez pas dans une liste récapitulative où l'utilisateur doit la chercher.
Valider des données sensibles côté client
N'envoyez pas de numéros de carte bancaire ni de mots de passe à travers une validation côté client. Ne les affichez pas dans la console du navigateur. Ne les enregistrez pas dans des journaux.
Validez les données sensibles uniquement sur le serveur, en HTTPS.
Ne pas valider les fichiers envoyés
Quelqu'un envoie un fichier de 100 mégaoctets. Votre serveur n'a plus de stockage. Quelqu'un envoie un fichier exécutable. Votre serveur attrape un virus.
Validez le type et la taille des fichiers sur le serveur. Vérifiez que le fichier est bien du type qu'il prétend être. Ne vous fiez pas seulement à l'extension ou au type MIME.
Validation en temps réel ou à l'envoi
La validation en temps réel vérifie chaque champ pendant la saisie. L'utilisateur voit tout de suite un message d'erreur s'il se trompe. Il peut corriger sur-le-champ.
Inconvénient : si vous affichez les erreurs trop tôt, l'utilisateur s'agace. N'affichez les erreurs qu'une fois le champ quitté (événement blur), pas pendant qu'il écrit encore.
La validation à l'envoi vérifie tout au moment de l'envoi du formulaire. L'utilisateur remplit tout le formulaire, puis voit toutes les erreurs d'un coup.
Inconvénient : l'utilisateur doit revenir corriger après avoir déjà envoyé. Cela casse le fil.
Bonne pratique : validez au blur (quand l'utilisateur quitte un champ) pour le retour en temps réel. Validez à l'envoi comme contrôle final. Affichez toutes les erreurs d'un coup si certaines échouent.
Validation selon le type de champ
Validation d'e-mail
La validation complète d'un e-mail est complexe (la RFC 5322 fait 60 pages). Dans la plupart des cas, vérifiez donc que la valeur contient un @ et un domaine avec const email = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;. Cela repère la plupart des e-mails invalides sans être assez strict pour rejeter de vraies adresses.
Validation de téléphone
Le format de téléphone varie selon les pays. Le format américain est (123) 456-7890, le format britannique +44 20 7946 0958 et l'Allemagne utilise +49 30 123456. Acceptez le format international, retirez les caractères non numériques sur le serveur et stockez le téléphone sous forme de texte plutôt que de nombre pour conserver les zéros initiaux dans certains pays.
Validation de mot de passe
Un bon mot de passe est long (au moins 12 caractères) et difficile à deviner. N'exigez pas de caractères spéciaux ni de mélange majuscules et minuscules : ces règles agacent les utilisateurs et n'améliorent pas la sécurité. De bonnes exigences sont au moins 12 caractères et l'absence de schémas courants (comme « 123456 » ou le nom de l'utilisateur). Utilisez un indicateur de robustesse pour montrer à l'utilisateur la solidité de son mot de passe.
Validation de date
Vérifiez que la date est dans le futur ou le passé selon le cas. Un formulaire d'inscription à un événement doit rejeter les dates passées. Un formulaire de date de naissance doit rejeter les dates futures.
Comment WEMASY gère la validation des formulaires
Les formulaires WEMASY incluent une validation côté client intégrée (champs obligatoires, format d'e-mail, etc.) pour un retour immédiat. À l'envoi des formulaires, les serveurs de WEMASY valident à nouveau toutes les données avant de les traiter. Les utilisateurs obtiennent un retour rapide et vos données sont protégées.
Découvrez les fonctions de validation dans votre offre WEMASY.