Gérer un formulaire avec HTML, CSS, JavaScript et PHP

Le besoin : collecter des informations sans perdre le contrôle du traitement

Un formulaire de contact est souvent l’un des premiers développements réalisés sur un site. Le HTML décrit les champs, le CSS organise l’affichage et JavaScript améliore l’expérience utilisateur. Cette première partie donne rapidement l’impression que tout est terminé. Pourtant, les données doivent encore être reçues et vérifiées par le serveur avant qu’un email puisse être envoyé. Sans cette étape, le formulaire ne fait qu’afficher une interface sans produire de résultat exploitable.

Le problème vient souvent du fait que chaque couche est traitée séparément. Le HTML impose quelques attributs, JavaScript contrôle à nouveau les valeurs et PHP applique encore d’autres règles. Si ces validations ne racontent pas la même chose, l’utilisateur peut voir un champ accepté dans le navigateur puis refusé par le serveur. Il faut donc construire une chaîne cohérente dans laquelle chaque étape possède un rôle précis.

Le HTML : poser une structure claire avant d’ajouter le comportement

Le formulaire commence par une structure HTML simple. Chaque champ possède un libellé visible, un nom exploitable côté serveur et un type adapté à son contenu. L’adresse email utilise par exemple type=’email’, tandis que le message repose sur une zone de texte. Les champs obligatoires sont indiqués avec l’attribut required, ce qui fournit une première aide au navigateur et aux technologies d’assistance.

Cette validation native améliore l’expérience, mais elle ne doit pas être considérée comme une sécurité. Un utilisateur peut désactiver JavaScript, modifier la requête ou appeler directement le fichier PHP. Le HTML sert donc à guider la saisie et à rendre le formulaire compréhensible. La décision finale appartient toujours au serveur, qui doit recevoir les données comme si elles pouvaient être incorrectes ou malveillantes.

Le JavaScript : valider rapidement et envoyer sans recharger la page

JavaScript intervient avant l’envoi pour détecter les erreurs les plus évidentes. Il vérifie les champs obligatoires, contrôle le format de l’email et affiche les messages près des zones concernées. Cette réponse immédiate évite un aller-retour inutile vers le serveur. Elle rend aussi le formulaire plus agréable, car l’utilisateur comprend directement ce qui doit être corrigé.

Lorsque les données sont valides, la démonstration utilise FormData pour récupérer les valeurs et simule un appel avec fetch(). Le bouton est désactivé pendant le traitement afin d’éviter plusieurs soumissions successives. Une réponse JSON fictive est ensuite affichée dans la page. Le mécanisme reste identique à celui d’un véritable envoi : seule l’adresse appelée est remplacée par une simulation locale.

La démonstration : montrer le cycle complet sans ouvrir un relais de spam

La partie publique de cette ressource n’envoie volontairement aucun email. Permettre à n’importe quel visiteur de choisir un destinataire ou d’utiliser librement une route d’envoi transformerait rapidement le site en relais de spam. Même avec un destinataire fixe, une démonstration publique pourrait être appelée automatiquement des centaines de fois. L’émission réelle est donc coupée, tandis que toutes les étapes visibles restent présentes.

La démo reproduit le déroulement complet : contrôle des champs, passage en état de chargement, réponse JSON, message de réussite et remise à zéro du formulaire. Un encart indique clairement qu’aucune donnée n’est transmise. Cette limitation ne retire rien au rôle pédagogique de l’exemple. Elle permet au contraire de distinguer le fonctionnement de l’interface de la responsabilité du serveur.

Le PHP : revalider toutes les données avant toute utilisation

Le fichier PHP fourni dans l’archive reçoit une requête POST et renvoie systématiquement du JSON. Il nettoie les chaînes, vérifie l’adresse email et refuse les champs incomplets. Un champ invisible, appelé honeypot, permet aussi de détecter une partie des robots qui remplissent automatiquement tous les champs. Lorsqu’il contient une valeur, la demande est rejetée sans poursuivre le traitement.

Cette validation serveur ne doit jamais dépendre du résultat obtenu en JavaScript. Les deux couches utilisent des règles proches, mais elles ne se font pas confiance. JavaScript améliore la saisie ; PHP protège le traitement. Cette séparation est essentielle dès qu’un formulaire peut déclencher un email, créer un compte, enregistrer une commande ou modifier des données.

L’envoi d’email : brancher la ressource sur son propre hébergement

Le fichier config.sample.php contient les paramètres à adapter. Il faut le copier sous le nom config.php, renseigner l’adresse qui recevra les messages et choisir l’adresse utilisée comme expéditeur. Le formulaire peut ensuite appeler directement serveur/send.php si les deux parties sont hébergées sur le même domaine. Le code JavaScript contient l’emplacement exact où remplacer la simulation par l’appel réel.

L’exemple utilise la fonction PHP mail() pour rester autonome. Sur un projet réel, un envoi SMTP avec PHPMailer ou une bibliothèque équivalente sera généralement plus fiable. Il permet de configurer un serveur authentifié, de mieux suivre les erreurs et d’améliorer la délivrabilité. La structure du formulaire ne change pas : seule la fonction chargée d’expédier le message doit être remplacée.

La sécurité : limiter les abus automatisés avant d’envoyer un message

Un honeypot bloque certains robots simples, mais il ne suffit pas pour une route publique très exposée. Il faut également limiter la fréquence des requêtes, vérifier leur origine et surveiller les volumes anormaux. Un captcha peut être ajouté si le formulaire reçoit trop de soumissions indésirables, mais il vaut mieux commencer par des protections moins gênantes pour les utilisateurs. La sécurité doit rester proportionnée au risque réel.

Le destinataire ne doit jamais provenir directement d’un champ envoyé par le navigateur. Il est défini dans la configuration serveur et reste inaccessible au visiteur. Cette règle empêche le script d’être utilisé pour envoyer des messages vers des adresses arbitraires. Les en-têtes sont également construits à partir de valeurs nettoyées afin d’éviter les injections et les comportements imprévus.

Les réponses JSON : conserver un contrat simple entre JavaScript et PHP

Le serveur renvoie toujours une structure prévisible avec un booléen success, un message et éventuellement les erreurs associées aux champs. JavaScript n’a donc pas besoin d’interpréter une page HTML ou un texte libre. Il sait immédiatement si l’envoi a réussi et peut mettre à jour l’interface. Ce contrat réduit les dépendances entre le formulaire et le fichier PHP.

La même organisation peut être reprise pour une inscription, une demande de devis ou un formulaire de support. Les champs changent, mais le cycle reste identique : saisir, valider, envoyer, traiter et répondre. En conservant une réponse JSON stable, il devient possible de faire évoluer la présentation sans modifier toute la partie serveur.