Ce que l'attribut Action du formulaire HTML fait réellement (et pourquoi c'est important)

L'attribut action d'un formulaire HTML indique au navigateur où envoyer les données du formulaire quand l'utilisateur clique sur soumettre. C'est l'URL qui reçoit la soumission, et sans elle, ton formulaire n'a nulle part où aller. Comprendre comment ça fonctionne, c'est la différence entre un formulaire de contact qui livre vraiment les messages et un formulaire qui ne fait rien en silence.

À quoi sert vraiment l'attribut action

Quand quelqu'un remplit un formulaire et clique sur soumettre, le navigateur rassemble toutes les valeurs des champs dans une requête et l'envoie à l'URL spécifiée dans l'attribut action . Cette URL s'appelle l'endpoint du formulaire. Le serveur qui se trouve à cet endpoint reçoit les données, les traite, et généralement renvoie une réponse.

Voici l'exemple le plus simple possible :

<form action="https://example.com/submit" method="POST">
  <input name="name" type="text"/>
  <button type="submit">Send</button>
</form>

Quand l'utilisateur clique sur "Envoyer", le navigateur envoie une requête POST à https://example.com/submit avec les données du formulaire jointes. Le serveur à cette adresse gère le reste.

Si tu omets l'attribut action complètement, le navigateur soumet le formulaire à l'URL de la page actuelle. C'est parfois utile pour les apps côté serveur, mais dans la plupart des cas, ça signifie que tes données ne vont nulle part d'utile.

Ce qu'on met dans l'URL du formulaire

L'URL du formulaire peut être :

• Une URL absolue comme https://api.example.com/contact . Ça envoie les données vers un serveur ou un service complètement différent.
• Une URL relative comme /submit ou submit.php . Le navigateur la résout par rapport au domaine de la page actuelle.
• Une chaîne vide ( action="" ). Soumet vers la page actuelle, pareil que si tu omettais l'attribut.

Pour la plupart des formulaires de contact réels, tu vas utiliser une URL absolue qui pointe soit vers ton propre script côté serveur (un fichier PHP, un endpoint Node.js, etc.), soit vers un service de backend de formulaire tiers. L'essentiel, c'est que quelque chose doit tourner à cette URL pour recevoir et traiter la requête.

Pourquoi la méthode est tout aussi importante que l'action

L'attribut method fonctionne avec action pour définir comment les données sont envoyées. Il y a deux options :

Pour les formulaires de contact, utilise toujours method="POST" . Les requêtes GET exposent les valeurs des champs dans la barre d'adresse du navigateur, se retrouvent stockées dans l'historique du navigateur, et ont des limites de longueur qui vont tronquer les messages plus longs. POST n'a aucun de ces problèmes.

Par défaut, les formulaires HTML envoient les données sous la forme application/x-www-form-urlencoded , qui encode les noms et valeurs des champs en une chaîne structurée. La plupart des backends et services de formulaires acceptent ce format sans configuration.

Le problème des sites statiques

C'est ici que les développeurs se heurtent à un mur. Si ton site est purement statique (des fichiers HTML simples hébergés sur GitHub Pages, Cloudflare Pages, ou des hosts similaires), il n'y a pas de code côté serveur qui tourne sur ton domaine. Tu ne peux pas juste pointer l'action de ton formulaire vers un script PHP parce qu'il n'y a pas de runtime PHP pour l'exécuter.

Ça signifie que ton URL d'action de formulaire doit pointer ailleurs complètement. Tes options sont :

• Écrire et héberger ton propre backend API (Node.js, Python, etc.) sur un serveur séparé
• Utiliser une fonction serverless (AWS Lambda, Cloudflare Workers)
• Utiliser un service de backend de formulaire qui te donne un endpoint de formulaire HTML prêt à l'emploi

La troisième option est la plus rapide pour la plupart des projets. Tu obtiens une URL à mettre directement dans ton attribut action et les soumissions commencent à arriver dans ta boîte de réception sans aucun code backend. Si tu veux savoir comment ça se compare à écrire ton propre gestionnaire côté serveur, la comparaison PHP vs formulaires serverless couvre clairement les compromis.

Utiliser un service d'endpoint de formulaire

Un service d'endpoint de formulaire comme Sendform.net fonctionne en te donnant une URL unique qui agit comme l'attribut action de ton formulaire. Tu pointes ton formulaire là-bas, et le service transfère les soumissions à ton email. Pas de backend nécessaire.

Voici à quoi ça ressemble en pratique :

<form action="https://sendform.net/en/!a8Kz3mXq12" method="POST">
  <input name="email" placeholder="[email protected]" required="" type="email"/>
  <textarea name="message" placeholder="Tell us more" required=""></textarea>
  <button type="submit">Send</button>
</form>

La mise en place est simple :

1. Connecte-toi à Sendform.net et crée un formulaire pour obtenir ton URL d'endpoint personnelle.
2. Ouvre l'onglet Intégration et copie l'endpoint.
3. Colle-le comme attribut action de ton formulaire avec method="POST" .
4. Assure-toi que ton formulaire a un <input/> avec name="email" et un <textarea> </textarea> avec name="message" .
5. Déploie ton site. Les soumissions arrivent dans ta boîte de réception des notifications.

Sendform a aussi un Snippet Builder dans l'onglet Intégration. Sélectionne "HTML" dans le sélecteur de framework, définis optionnellement une URL de redirection pour une page de remerciement personnalisée, et active un champ honeypot pour la protection contre le spam basique. Ça génère le snippet de formulaire complet prêt à copier.

L'attribut formaction sur les boutons

Il y a un cousin moins connu de l'attribut action du formulaire : formaction sur les boutons de soumission individuels. Ça remplace l'attribut action du formulaire pour ce bouton spécifique seulement.

<form action="/default-endpoint" method="POST">
  <input name="query" type="text">
  <button type="submit">Save</button>
  <button formaction="/preview-endpoint" type="submit">Preview</button>
</input></form>

Cliquer sur "Enregistrer" envoie les données à /default-endpoint . Cliquer sur "Aperçu" envoie les mêmes données à /preview-endpoint à la place. L'attribut HTML formaction est supporté dans tous les navigateurs modernes et est défini dans la norme HTML vivante WHATWG.

C'est utile pour les formulaires multi-actions (enregistrer vs publier, enregistrer vs supprimer) sans avoir besoin de JavaScript pour changer l'action du formulaire dynamiquement.

Ce qui se passe après la soumission

Après que le navigateur envoie la requête à l'URL d'action du formulaire, la réponse du serveur détermine ce que l'utilisateur voit ensuite :

• Réponse de redirection (HTTP 302/303) : Le serveur envoie le navigateur vers une nouvelle URL. Motif courant pour afficher une page "merci".
• Réponse HTML : Le serveur renvoie une page directement, qui remplace la page actuelle dans le navigateur.
• Pas de redirection configurée : Avec Sendform, si tu n'as pas défini d'URL de redirection, le service renvoie sa propre page de confirmation.

Si tu veux garder l'utilisateur sur ton propre site après la soumission, configure une URL de redirection pointant vers ta propre page de remerciement. Dans Sendform, tu définis ça dans le Snippet Builder ou les paramètres du formulaire. Le navigateur atterrira sur ta page au lieu de l'écran de confirmation par défaut du service.

Pour les développeurs qui veulent gérer les soumissions sans rechargement de page complet, tu peux intercepter la soumission du formulaire avec JavaScript, envoyer les données via fetch() , et mettre à jour l'interface toi-même. Dans ce cas, l'attribut action sert toujours comme fallback utile pour les utilisateurs avec JavaScript désactivé.

Erreurs courantes

• Utiliser GET au lieu de POST pour les formulaires de contact. Les valeurs des champs incluant les adresses email se retrouvent dans les logs du serveur et l'historique du navigateur.
• Pointer l'action vers un fichier statique. Les fichiers HTML et CSS ne peuvent pas traiter les soumissions de formulaire. L'URL d'action a besoin d'un serveur ou d'un service derrière elle.
• Oublier l'attribut action complètement. Le formulaire soumet vers la page actuelle, ce qui généralement le recharge simplement sans effet.
• Noms de champs qui ne correspondent pas. Si l'endpoint attend name="email" et ton input a name="Email" , la soumission échoue la validation silencieusement côté serveur.
• Utiliser une URL relative pour un endpoint cross-origin. Si ton backend de formulaire se trouve sur un domaine différent, tu as besoin de l'URL absolue complète incluant le protocole.

Pour les utilisateurs de Webflow spécifiquement, la mise en place de l'action du formulaire a quelques bizarreries spécifiques à la plateforme qui valent le coup de connaître. Le guide du formulaire de contact Webflow couvre comment pointer un formulaire Webflow vers un endpoint externe sans écrire de code côté serveur.

Obtiens une vraie URL d'action de formulaire HTML en moins d'une minute

Sendform.net te donne un endpoint de formulaire HTML prêt à l'emploi que tu peux mettre directement dans l'attribut action de ton formulaire. Pas de backend, pas de JavaScript nécessaire. Pointe ton formulaire de site statique vers ton endpoint personnel et les soumissions arrivent dans ta boîte de réception instantanément.

Crée Ton Endpoint de Formulaire →