Rédigé par Rédaction CyberSDF / 17 septembre 2026

Comprendre le courriel : du serveur au HTML du message

Verdict : SMTP transporte le message, IMAP permet de retrouver sa boîte, et MIME réunit une version texte, une version HTML et les pièces jointes. Pour envoyer un HTML fiable, gardez le sens dans le texte, utilisez une structure simple et traitez l’affichage comme une compatibilité à vérifier.

Un courriel associe plusieurs couches qui se confondent dans une application de messagerie. L’adresse du destinataire, le transport entre serveurs, le stockage de la boîte et la mise en forme du contenu répondent à des problèmes différents. Les séparer permet de diagnostiquer un message bloqué, une pièce jointe absente ou un affichage dégradé sans tout attribuer au HTML.

Le trajet d’un message, du bouton Envoyer à la boîte de réception

Le protocole SMTP organise le transport du courrier entre agents. Le logiciel de messagerie remet le message à un serveur de soumission, puis des serveurs SMTP l’acheminent vers le domaine du destinataire. Le nom du protocole décrit le transport, pas l’écran qui affiche le message.

Une fois le message arrivé, le logiciel de lecture accède à la boîte avec IMAP4rev2. IMAP permet de lister les dossiers, rechercher un message et récupérer tout ou partie de son contenu. Un webmail ajoute une interface dans le navigateur, mais cette interface reste distincte du message lui-même.

Un échec de réception et un mauvais rendu HTML se cherchent à deux endroits différents : le premier commence par la remise SMTP, le second par l’analyse des parties MIME et les règles du logiciel de lecture.

L’adresse affichée et l’enveloppe de transport

Le champ To visible dans le message fait partie de ses en-têtes. L’enveloppe utilisée pendant la remise SMTP est une information de transport séparée. Le format Internet Message décrit les en-têtes et le corps du message, tandis que SMTP traite la transaction de remise.

Cette distinction explique deux situations courantes. Plusieurs destinataires peuvent être affichés dans To ou Cc alors que le serveur reçoit une liste de destinataires différente. À l’inverse, une adresse peut recevoir le message alors qu’elle n’apparaît pas dans l’en-tête visible, par exemple lors d’une copie cachée. Lire les deux couches est plus fiable que de déduire le trajet à partir de l’écran.

MIME rassemble texte, HTML et pièces jointes

MIME décrit la nature et le codage des parties d’un message. Le type multipart/alternative, défini dans RFC 2046, permet de proposer le même contenu sous plusieurs représentations. Une partie text/plain fournit une lecture sobre ; une partie text/html apporte la mise en forme ; une autre structure peut porter une pièce jointe.

L’ordre et les en-têtes comptent. Chaque partie possède son propre Content-Type et son encodage. Le séparateur boundary indique où une partie commence et où la suivante prend le relais. Le HTML n’est donc pas envoyé comme une petite page Web autonome : il est une partie d’un message, entourée d’en-têtes et souvent accompagnée d’une représentation texte.

Content-Type: multipart/alternative; boundary="frontiere"

--frontiere
Content-Type: text/plain; charset="utf-8"

Bonjour, votre relevé est disponible.

--frontiere
Content-Type: text/html; charset="utf-8"

<p>Bonjour, <strong>votre relevé est disponible</strong>.</p>

--frontiere--

Le texte brut porte l’information principale. Le HTML peut ensuite ajouter une hiérarchie visuelle, un bouton et une mise en page adaptée à la largeur disponible. Une pièce jointe suit la même logique de partie déclarée, avec son type et son encodage.

Une démonstration locale avec Python

Pour rendre MIME concret, Python 3.12.3 a construit puis relu un fichier mime-example.eml avec la bibliothèque standard email. Le message contenait un texte court et son équivalent HTML, sans connexion à un serveur de courrier.

from email import policy
from email.message import EmailMessage

message = EmailMessage(policy=policy.SMTP)
message["From"] = "expediteur@example.net"
message["To"] = "lecteur@example.net"
message["Subject"] = "Exemple de message multipart"
message.set_content("Bonjour, voici la version texte du message.\n")
message.add_alternative(
    '<!doctype html><p>Bonjour, voici la version HTML.</p>\n',
    subtype="html",
)
open("mime-example.eml", "wb").write(message.as_bytes())

Le 17 septembre 2026, le fichier obtenu mesurait 656 octets. Sa lecture retournait les parties text/plain et text/html, avec 45 caractères pour le texte, 91 pour le HTML et la propriété multipart à True. Ces valeurs rendent visible la différence entre le contenu écrit et l’emballage MIME qui le transporte.

Cette démonstration construit un fichier local ; elle ne mesure pas le rendu dans chaque client de messagerie.

Pourquoi l’HTML de courrier doit rester sobre

Un client de messagerie affiche le contenu dans un environnement plus contraint qu’un navigateur généraliste. La largeur peut être réduite, les images distantes peuvent attendre une action et les propriétés CSS disponibles peuvent varier. Placez donc l’information dans du texte réel, donnez une alternative aux images utiles et gardez la mise en page compréhensible lorsque les ornements disparaissent.

Une structure en tableaux de présentation reste un choix pratique pour une mise en page alignée dans de nombreux clients. Elle doit rester séparée du sens : role="presentation" sur les tableaux de mise en page, un titre lisible, des paragraphes courts et des liens identifiables. Les styles essentiels peuvent être placés directement sur les éléments, avec une largeur fluide et une marge intérieure qui supporte un petit écran.

Le standard HTML du WHATWG décrit la syntaxe et la sémantique du HTML pour le Web. Il ne transforme pas chaque client de messagerie en navigateur identique : l’HTML d’un courriel se conçoit pour une famille d’affichages connue, avec un contenu qui garde sa valeur quand une règle de style manque.

Un modèle minimal à adapter

<table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">
  <tr>
    <td style="padding:24px;background:#f4f5f6;">
      <table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">
        <tr>
          <td style="padding:24px;background:#ffffff;">
            <h1 style="margin:0 0 16px;font:700 24px Arial,sans-serif;">
              Votre relevé est disponible
            </h1>
            <p style="font:16px/1.5 Arial,sans-serif;">
              Le texte reste lisible avant l'activation des images.
            </p>
            <p>
              <a href="https://example.org/" style="color:#8a4b08;">Ouvrir le relevé</a>
            </p>
          </td>
        </tr>
      </table>
    </td>
  </tr>
</table>

Le modèle met en avant le contenu sans incorporer de texte dans une image. Remplacez l’adresse d’exemple par une URL HTTPS durable, gardez le lien explicite et adaptez les couleurs au contraste recherché. Un titre, un paragraphe et une action suffisent pour vérifier le trajet complet avant d’ajouter une image ou un bloc plus décoratif.

Les réglages qui évitent les confusions

Pour envoyer une newsletter ou une notification, choisissez d’abord le service SMTP chargé de la remise et la méthode d’authentification qu’il demande. Pour lire la boîte sur plusieurs appareils, IMAP conserve l’état des dossiers côté serveur. Pour archiver un message, conservez le fichier original avec ses en-têtes et ses pièces MIME plutôt qu’une capture d’écran du rendu.

Quand une pièce jointe semble absente, inspectez le type MIME, le nom déclaré et la partie correspondante avant de modifier le HTML. Quand le bouton s’affiche mal, vérifiez d’abord l’URL et la représentation text/plain, puis réduisez la mise en page à un bloc simple. Cette séquence sépare la remise, le contenu et l’affichage.

Relier l’ancien Web2Mail aux usages actuels

Un formulaire de contact historique comme Web2Mail pour Dotclear répondait à un besoin précis : transmettre le message d’un visiteur vers une boîte. Le fonctionnement d’un formulaire, du serveur qui reçoit la requête au service qui remet le courriel, reste plus large que l’apparence du formulaire.

Pour replacer cette décision dans un choix d’outil, consultez la grille de choix logiciel et les principes des standards du Web. Ces ressources permettent de distinguer une fonction annoncée, un format échangé et un résultat réellement observable.