Cursor
FigmaFORMULAIRE CONTACT VALIDATION
Prérequis
- Formulaire React existant ou composant UI champs texte/email
- Route API ou Server Action pour l’envoi email
- Environnement de test avec logs serveur accessibles
- Service transactionnel configuré (Resend, SendGrid ou équivalent)
Un formulaire contact efficace combine validation claire pour l’utilisateur et garde-fous côté serveur contre le spam automatisé. Sur Next.js, une Server Action ou une route API centralise la logique métier. Vous allez poser une double validation, des mécanismes anti-spam pragmatiques et des retours accessibles sans friction excessive.
Validation accessible côté client
Associez chaque champ à un `<label>` et des messages d’erreur liés via `aria-describedby`. Validez au blur et à la soumission ; annoncez les erreurs sans perdre le focus.
Types HTML (`type="email"`, `autocomplete`) comme première ligne de défense. États erreur visuels + texte explicite, jamais couleur seule.
Bouton submit explicite (« Envoyer ma demande »). Désactivez le double envoi (`aria-busy` ou disabled pendant le POST).
Traitement serveur robuste
Dans la Server Action ou l’API route : parsez le corps, refusez les payloads incomplets (400). Normalisez l’email et vérifiez le format avec une librairie robuste.
Limitez la taille des champs pour éviter les abus. Retournez des messages d’erreur génériques à l’utilisateur ; logguez le détail côté serveur (IP, user-agent) pour analyse.
Envoyez l’email via un service transactionnel avec template et reply-to sur l’email soumis si pertinent.
Anti-spam pragmatique
Champ honeypot caché visuellement (`aria-hidden`, hors tab order) : si rempli, rejeter silencieusement sans erreur visible (évite le feedback aux bots).
Rate limiting par IP ou token (edge middleware, Upstash, limite hébergeur Vercel). Délai minimum entre affichage et soumission via timestamp signé.
Pour sites très exposés : CAPTCHA turnstile/hCaptcha en complément, pas en première intention — impact accessibilité et conversion.
Erreurs fréquentes
Validation client uniquement : spam et injections passent.
Messages d’erreur serveur techniques exposés à l’utilisateur (« SQL error »).
Honeypot visible ou focusable : utilisateurs légitimes bloqués.
Pas de test parcours erreur réseau et timeout : UX brisée sans feedback.
Ce qu’il faut retenir
Double validation client + serveur, messages accessibles.
Honeypot + rate limit couvrent la majorité du spam.
Tester succès, erreur validation, erreur réseau et honeypot.
Server Action pour formulaire same-origin simple ; API route si multi-clients.
FAQ
Server Action pour un formulaire unique same-origin simple. API route si vous exposez un endpoint consommé par plusieurs clients ou webhooks.
Non. Honeypot + rate limit + validation serveur suffisent sur la plupart des sites B2B. Ajoutez CAPTCHA si spam persistant après mesure.
Script curl avec honeypot rempli (doit échouer silencieusement), rafale de requêtes (rate limit), payload invalide (400 avec message accessible).