HTML mail reçu : exemple de mail reçu et formulaire de site web expliqués
Le HTML d’un mail reçu peut sembler obscur au premier abord. Pourtant, comprendre la structure d’un exemple de mail reçu — qu’il provienne d’un formulaire de site web ou d’un client de messagerie — est une compétence de plus en plus utile, y compris dans les services publics numériques. Ce guide décrypte chaque étape, du code source d’un courriel entrant à la mise en place d’un formulaire de contact opérationnel.
Qu’est-ce qu’un mail reçu en HTML ?
Un mail reçu en HTML est un courriel dont le contenu est structuré à l’aide du langage de balisage HTML (HyperText Markup Language). Contrairement à un email en texte brut, il intègre une mise en forme visuelle : titres, couleurs, images, boutons cliquables, colonnes. La quasi-totalité des communications professionnelles — newsletters, confirmations de formulaire, alertes administratives — utilisent ce format.
Lorsque vous ouvrez un tel message dans votre client de messagerie (Outlook, Gmail, Thunderbird), vous voyez le rendu visuel. Mais en coulisses, c’est du code HTML qui structure chaque élément affiché. Savoir lire ce code permet de vérifier l’authenticité d’un message, d’identifier un phishing ou de diagnostiquer un problème d’affichage.
Pourquoi décrypter la structure HTML d’un mail reçu ?
Plusieurs situations concrètes justifient cette démarche. Dans un service informatique d’une collectivité territoriale, un agent peut recevoir un courriel dont la mise en forme est défectueuse. Comprendre la structure HTML permet d’identifier la cause : balise mal fermée, style en ligne absent, image non chargée.
De même, un responsable de la communication d’un établissement public souhaitant reproduire un modèle reçu devra inspecter son code source. Enfin, dans le cadre de la lutte contre les cyberattaques, repérer les anomalies dans le HTML d’un mail suspect est une compétence transversale précieuse.
Exemple de mail reçu en HTML : anatomie d’un code type
Voici la structure d’un exemple de mail reçu classique, tel qu’il apparaît dans la source d’un courriel standard. Chaque partie remplit une fonction précise.
Le DOCTYPE et les balises de base
Tout email HTML commence par une déclaration DOCTYPE, suivie des balises <html>, <head> et <body>. Le <head> contient les métadonnées (encodage, viewport, feuille de style). Le <body> renferme le contenu visible par le destinataire.
Contrairement aux pages web modernes, les emails HTML n’utilisent pas de CSS externe ni de JavaScript. Les styles sont appliqués en ligne (attribut style sur chaque balise) pour garantir la compatibilité avec tous les clients de messagerie, qui interprètent différemment les feuilles de style.
La structure en tableau (table layout)
La mise en page d’un email HTML repose historiquement sur des balises <table>, <tr> (ligne) et <td> (cellule). Cette approche, héritée des années 2000, reste la plus fiable en 2026 pour assurer un rendu cohérent sur Outlook, Gmail et les clients mobiles.
Un tableau principal (width='600') centre le contenu. À l’intérieur, des sous-tableaux organisent l’en-tête, le corps du message et le pied de page. Cette structure en couches est la colonne vertébrale de tout exemple de mail reçu bien formé.
Exemple concret de code HTML pour un mail de confirmation
Voici un exemple simplifié de code source d’un mail de confirmation reçu après soumission d’un formulaire de site :
<!DOCTYPE html>
<html lang='fr'>
<head>
<meta charset='UTF-8'>
<meta name='viewport' content='width=device-width, initial-scale=1.0'>
<title>Confirmation de votre demande</title>
</head>
<body style='margin:0; padding:0; background-color:#f4f4f4;'>
<table width='100%' cellpadding='0' cellspacing='0'>
<tr>
<td align='center'>
<table width='600' cellpadding='20' cellspacing='0' style='background:#ffffff;'>
<tr>
<td style='font-family:Arial,sans-serif; font-size:16px; color:#333333;'>
<h1 style='font-size:22px; color:#1a73e8;'>Votre demande a bien été reçue</h1>
<p>Bonjour,</p>
<p>Nous avons bien reçu votre message soumis via le formulaire de contact. Notre équipe vous répondra sous 48 heures ouvrées.</p>
<p style='color:#888888; font-size:13px;'>Cet email est envoyé automatiquement, merci de ne pas y répondre.</p>
</td>
</tr>
</table>
</td>
</tr>
</table>
</body>
</html>
Ce modèle illustre les bonnes pratiques : styles en ligne, tableau centré à 600 pixels, typographie simple, message clair. Il constitue la base de tout mail reçu après soumission d’un formulaire de site web.
Comment fonctionne un formulaire de site web qui génère un mail ?
Un formulaire de contact HTML (balise <form>) collecte les données saisies par l’utilisateur. Mais le HTML seul ne peut pas envoyer d’email : il ne gère que l’affichage. L’envoi nécessite un traitement côté serveur.
La balise form et ses attributs essentiels
La balise <form> possède deux attributs clés. L’attribut action indique l’URL du script qui traitera les données (généralement un fichier PHP). L’attribut method définit la méthode d’envoi : POST est recommandé pour les formulaires de contact, car il n’expose pas les données dans l’URL.
À l’intérieur, les champs (<input>, <textarea>, <select>) collectent les informations. Le champ <input type='email'> valide automatiquement le format de l’adresse saisie, réduisant les erreurs avant même le traitement serveur. Pour aller plus loin sur les formulaires administratifs dématérialisés, consultez notre article sur le Cerfa permis de construire et les démarches en ligne.
Le traitement PHP : de la soumission à l’envoi du mail
En PHP, la fonction mail() ou une bibliothèque comme PHPMailer permet d’envoyer un email structuré en HTML après réception du formulaire. Le script récupère les données ($_POST['nom'], $_POST['email']…), les valide, puis compose le corps du message en HTML avant de l’envoyer au destinataire.
Une bonne pratique consiste à envoyer deux emails simultanément : un accusé de réception au visiteur (le mail reçu HTML visible par l’utilisateur) et une notification interne à l’équipe. Les services publics en ligne utilisent exactement ce mécanisme pour leurs portails de demande.
Validation et sécurité du formulaire
La validation des données est une étape non négociable. Côté client (navigateur), les attributs HTML5 (required, type='email', maxlength) offrent un premier niveau de contrôle. Côté serveur, le script PHP doit filtrer et nettoyer chaque champ pour prévenir les injections et le spam.
L’ajout d’un système anti-spam de type CAPTCHA (reCAPTCHA Google, Honeypot) est fortement recommandé sur tout formulaire de site exposé au public. Sans cette protection, le formulaire devient rapidement une cible pour l’envoi massif de messages indésirables.
Bonnes pratiques pour créer un mail HTML reçu lisible par tous
La compatibilité entre clients de messagerie est le principal défi du design d’email HTML. Outlook (très répandu dans les administrations) interprète différemment certaines propriétés CSS par rapport à Gmail ou Apple Mail. Voici les règles fondamentales à respecter.
Règles de mise en forme compatibles
- Toujours utiliser les styles en ligne : pas de feuilles de style externes, pas de balise
<style>dans le<body>pour les propriétés critiques. - Largeur fixe à 600 pixels : standard universel pour les clients de messagerie desktop.
- Polices système : Arial, Helvetica, Georgia. Les polices web (Google Fonts) ne sont pas supportées par Outlook.
- Attribut alt sur chaque image : de nombreux clients de messagerie bloquent les images par défaut. Le texte alternatif garantit la lisibilité du message.
- Éviter le JavaScript : tous les clients de messagerie le bloquent pour des raisons de sécurité.
- Tester sur plusieurs clients : des outils comme Litmus ou Email on Acid permettent de prévisualiser le rendu sur une vingtaine de clients simultanément.
La gestion du responsive dans les emails HTML
Depuis 2026, plus de 60 % des emails sont ouverts sur mobile. Les media queries CSS (@media) permettent d’adapter la mise en page selon la taille de l’écran, mais leur support varie selon les clients. Gmail supporte désormais les media queries dans la plupart de ses versions, ce qui simplifie le développement.
Une approche pragmatique consiste à concevoir en mobile-first : un tableau à colonne unique, des polices d’au moins 14px, des boutons larges et facilement cliquables. Le tableau passe ensuite à deux colonnes sur desktop via les media queries. Pour mieux appréhender les outils numériques dans un contexte pédagogique ou administratif, notre guide sur EcoleDirecte et les plateformes numériques illustre comment ces interfaces sont structurées.
Formulaire de site et mail reçu : les erreurs fréquentes à éviter
La mise en place d’un formulaire de contact générant un mail HTML reçu lisible concentre plusieurs pièges techniques. Les identifier en amont évite des correctifs coûteux.
Erreurs côté formulaire HTML
- Oublier l’attribut
namesur les champs : sans cet attribut, la donnée n’est pas transmise au serveur par la méthode POST. - Utiliser
method='GET'pour un formulaire de contact : les données sensibles apparaissent dans l’URL et sont journalisées par le serveur. - Ne pas prévoir de message de confirmation visible : l’utilisateur doit savoir que sa soumission a été prise en compte, au-delà de l’email de confirmation.
Erreurs côté mail HTML envoyé
- Ne pas déclarer le Content-Type en HTML dans les en-têtes PHP : sans
Content-Type: text/html; charset=UTF-8, le code HTML s’affiche brut dans la boîte de réception. - Utiliser des images hébergées localement sans URL absolue : les images doivent être référencées par leur URL complète (https://…), pas par un chemin relatif.
- Ignorer l’encodage des caractères : les accents et caractères spéciaux doivent être encodés en UTF-8, sinon ils s’affichent en caractères illisibles dans le mail reçu.
La gestion rigoureuse des documents numériques et des formulaires administratifs dématérialisés est également au coeur de processus comme la demande de certificat d’immatriculation via le formulaire Cerfa 13750, où la confirmation par email joue un rôle central dans le suivi du dossier.
Outils pour tester et déboguer un mail HTML reçu
Plusieurs outils gratuits ou payants permettent de vérifier qu’un exemple de mail reçu s’affiche correctement avant tout envoi en production.
- Mailtrap : serveur SMTP de test qui capture les emails sans les envoyer réellement. Idéal pour déboguer le rendu HTML en phase de développement.
- Litmus : prévisualisation sur plus de 90 combinaisons de clients et systèmes d’exploitation. Solution payante, incontournable pour les campagnes à grande échelle.
- Mail Tester (mail-tester.com) : analyse le score de délivrabilité d’un email, vérifie les en-têtes SPF, DKIM et DMARC.
- W3C Markup Validator : valide la syntaxe HTML du code source du mail pour identifier les balises mal fermées ou les attributs invalides.
- Can I Email (caniemail.com) : référence la compatibilité de chaque propriété CSS et HTML par client de messagerie, l’équivalent de Can I Use pour les emails.
Ce qu’il faut retenir
- Un mail HTML reçu repose sur une structure en tableaux, avec des styles appliqués en ligne, une largeur fixe de 600 pixels et des polices système pour garantir la compatibilité universelle entre clients de messagerie.
- Un formulaire HTML seul ne peut pas envoyer d’email : il faut un traitement côté serveur (PHP avec la fonction mail() ou PHPMailer) qui compose et expédie le message HTML après validation des données saisies.
- La sécurité et la validation sont non négociables : filtrage des données côté serveur, protection anti-spam, encodage UTF-8 et en-têtes MIME corrects conditionnent la fiabilité du dispositif.
- Le test multi-client est indispensable avant tout déploiement : Outlook, Gmail et les clients mobiles interprètent différemment le HTML et le CSS, rendant les outils de prévisualisation incontournables.
Conclusion
Maîtriser le HTML d’un mail reçu et la mécanique d’un formulaire de site web qui génère cet email est une compétence technique désormais transversale. Elle concerne aussi bien les développeurs que les responsables de services numériques, les agents chargés de la communication institutionnelle ou les gestionnaires de portails administratifs. En comprenant chaque couche — du formulaire HTML au code source du message reçu —, vous gagnerez en autonomie pour diagnostiquer, améliorer ou auditer vos dispositifs de contact en ligne. Abonnez-vous à La Lettre du Secteur Public pour suivre les évolutions des outils numériques dans la sphère publique.







