Espace d’aperçu des modèles d’e-mail

Testez une inscription,
vérifiez l’e-mail transactionnel de bout en bout

Une maquette montre à quoi l’e-mail devrait ressembler ; une réception réelle révèle ce qui a été envoyé. Avec une adresse dédiée, vérifiez ensemble le sujet, le contenu et l’action à effectuer.

Commencer le test dans la boîte de réception Voir un exemple de vérification

01 / Ce que vous pouvez vérifier

L’intégralité du contenu, la lisibilité du code, la structure HTML et la mise en page de base.

02 / Ce que cela ne remplace pas

Les tests de compatibilité avec tous les clients de messagerie sur ordinateur et mobile, ni la garantie que l’e-mail arrivera dans la boîte de réception.

03 / À distinguer d’abord

Si vous n’avez pas reçu l’e-mail, commencez par le dépannage de réception ; s’il est arrivé mais s’affiche mal, vérifiez le modèle.

Avant de commencer

Préparez un scénario de test reproductible

Fixez d’abord l’environnement, les données et la version du modèle. Ne changez que l’adresse de réception à chaque essai pour pouvoir reproduire facilement le problème.

À préparer pour ce test

1
Un environnement de préproduction accessible
Vérifiez que vous êtes autorisé à déclencher un e-mail d’inscription ou de réinitialisation du mot de passe. Contrôlez les indicateurs d’environnement et le domaine de rappel pour éviter qu’un test ne passe en production.
2
Un compte sans données client réelles
Utilisez un nom fictif et des données de test. Ne saisissez pas d’adresse client, d’informations de paiement ni d’identifiants de production.
3
Le modèle et la langue à vérifier
Notez la version du modèle, le sujet attendu, la durée de validité du code et la langue de ce test. Pour comparer avant et après une modification, conservez les mêmes données d’entrée.
4
Une nouvelle adresse e-mail de test pour les codes
Dans la boîte de réception de la page d’accueil copiez l’adresse actuellement valide. Utilisez une adresse différente à chaque test pour ne pas confondre un ancien code avec le résultat du test en cours.

Test ponctuel

Réception temporaire, à jeter une fois le test terminé

Pour les inscriptions, réinitialisations de mot de passe et vérifications OTP qui se font en quelques minutes. Une adresse temporaire est valide 3 heures par défaut ; chaque prolongation ajoute 3 heures, dans la limite de 24 heures par adresse.

Réception uniquement, sans envoi ; les e-mails ne peuvent pas être récupérés après expiration. Enregistrez les captures d’écran et les notes anonymisées dont vous avez besoin avant l’expiration de l’adresse.

Utiliser une adresse temporaire →

Nouveau test le lendemain

Un alias fixe avec transfert des e-mails entrants

Pour les tests de régression continus, les notifications périodiques et les comptes de test qui doivent recevoir des e-mails le lendemain. Connectez-vous pour créer un alias et transférer les e-mails entrants vers votre véritable boîte de réception.

La mise en page après transfert peut dépendre du client de messagerie destinataire. Dans vos notes, précisez si l’e-mail a été consulté directement dans la boîte temporaire ou après transfert par alias.

Se connecter et utiliser un alias →

Test réel d’un e-mail d’inscription

Quatre étapes, sans simuler l’envoi

Cette page est un guide de vérification ; elle n’envoie pas d’e-mail à la place de votre application. Le véritable envoi doit être déclenché par un système de test que vous êtes autorisé à utiliser.

Générez et copiez une adresse

Ouvrez la page d’accueil, attendez la génération de l’adresse et vérifiez le temps restant. Copiez l’adresse complète, puis vérifiez qu’elle ne contient ni espace superflu ni suffixe manquant une fois collée.

Déclenchez le parcours d’inscription

Dans l’environnement de préproduction, soumettez le compte de test et notez l’heure d’envoi ainsi que la version du modèle. Vérifiez que l’application a réellement lancé une tâche d’envoi, et pas seulement affiché un message de confirmation.

Attendez la réception effective

Revenez à la boîte de réception qui s’actualise automatiquement. Notez l’heure de réception et évitez de relancer l’envoi plusieurs fois, ce qui brouillerait les résultats. Si l’e-mail tarde à arriver, vérifiez d’abord l’adresse et les journaux d’envoi.

Ouvrez l’e-mail complet

Ouvrez le sujet correspondant, vérifiez l’expéditeur et le code de ce test, puis examinez le corps du message et le lien d’action. Ne validez pas le modèle sur la seule base de l’aperçu dans la liste.

Un scénario par test : associez l’adresse de réception, l’identifiant de requête et l’heure d’envoi à la fiche de test de l’application. Lorsque vous changez d’adresse pour le test suivant, l’ancienne est invalidée. Enregistrez d’abord les éléments de preuve nécessaires.

Espace de vérification du contenu

Lisez d’abord le contenu, puis examinez la mise en page

Les deux exemples statiques ci-dessous illustrent respectivement un e-mail avec code de vérification et une notification de transaction. Ils servent à expliquer la méthode de vérification ; ce ne sont ni de véritables notifications de compte ni une preuve de compatibilité avec les clients de messagerie.

Exemple A · Code de vérification Point à vérifier : réaliser une action

Votre code de connexion Netflix

Netflix · demo@netflix.example

NETFLIX

Saisissez ce code pour vous connecter

Un nouvel appareil tente de se connecter à votre compte. Si vous êtes à l’origine de cette tentative, saisissez le code ci-dessous sur la page de connexion.

604917

Validité: Valable pendant 15 minutes
Appareil: Chrome · macOS
Lieu: Shanghai, Chine

Cet e-mail est un exemple présenté par Tempcase et n’a aucun lien avec Netflix. Le code de vérification affiché ne permet pas de se connecter à un vrai compte.

Question de validation : Sans image, l’utilisateur peut-il reconnaître la tentative de connexion concernée, copier le code complet et savoir quand il expire ?

Exemple B · Notification de transaction Point à vérifier : contrôler un relevé détaillé

Reçu de course du mercredi · ¥46.80

Uber · demo@uber.example

Uber

Merci d’avoir effectué cette course

Ce reçu de course sert à vérifier la mise en page d’un e-mail transactionnel.

¥46.80

Reçu: UBR-58K2-7731Q
Itinéraire: Temple Jing’an → Qiantan
Course: 12.4 km / 24 minutes
Devise: CNY

Cet e-mail est un exemple présenté par Tempcase et n’a aucun lien avec Uber. Il ne correspond ni à une course réelle ni à un paiement réel.

Question de validation : Le numéro, le montant, la devise et l’itinéraire correspondent-ils bien entre eux ? Sur un écran étroit, le long numéro reste-t-il entièrement lisible ?

Cinq points de contrôle pour examiner le contenu

01Sujet: Il doit indiquer clairement l’objet de l’action ; évitez les sujets vagues comme « Notification ». Vérifiez que les variables du modèle ont bien été remplacées et qu’aucune donnée personnelle superflue n’est exposée.
02Expéditeur: Le nom affiché et l’adresse doivent correspondre à la configuration de l’environnement de test. Un nom identique ne garantit pas l’identité de l’expéditeur ; cet aperçu ne remplace pas la vérification de l’authentification des e-mails et des journaux d’envoi.
03Bloc du code de vérification: Vérifiez que les zéros initiaux, le nombre de chiffres et le code copié correspondent au contenu du message. Ne placez pas le code uniquement dans une image et évitez tout espacement ou retour à la ligne susceptible de rendre les chiffres ambigus.
04Durée de validité: La durée de validité indiquée dans l’e-mail doit correspondre aux règles de vérification côté serveur. Les 15 minutes de l’exemple concernent le code de vérification ; elles n’ont rien à voir avec la durée par défaut de 3 heures de l’adresse temporaire.
05Lien d’action: Si votre modèle contient un lien de vérification ou de réinitialisation, contrôlez d’abord sa destination, l’environnement et les règles d’expiration. Effectuez la vérification uniquement dans un système de test autorisé ; n’ouvrez pas un lien d’origine inconnue pour valider le modèle.

Comparer le HTML et le texte brut

Au-delà de l’apparence, vérifiez que le message reste utilisable en mode dégradé

Examinez le résultat dans la zone de lecture, vérifiez la structure dans le code source HTML, puis contrôlez la version texte brut dans le système d’envoi. Un affichage correct du HTML ne signifie pas que l’e-mail contient une version texte brut exploitable.

Méthode et critères de validation pour un même e-mail
Point de contrôle	À observer dans le HTML	À comparer dans le texte brut	Critère de validation de ce test
Retours à la ligne sur petit écran	Réduisez la largeur du navigateur et observez le code, les longs numéros de commande et le texte des boutons. Repérez les largeurs fixes et les éléments qui ne peuvent pas passer à la ligne.	Vérifiez les séparateurs dans les longs paragraphes, les numéros et les URL. Le contenu doit rester compréhensible sans dépendre de la largeur des colonnes d’un tableau.	Les informations essentielles ne sont pas tronquées et les actions principales ne nécessitent pas de défilement horizontal.
Remplacement des polices	Vérifiez la mise en page sans la police de la marque, en particulier pour les caractères chinois, les chiffres, les montants et la hauteur des boutons.	Conservez des libellés et des paragraphes explicites. N’alignez pas un tableau essentiel avec des espaces qui supposent une police à chasse fixe.	La hiérarchie reste claire avec les polices système, et aucun chiffre ni signe de ponctuation ne disparaît.
Images manquantes	Prévoyez le cas où les images distantes ne se chargent pas : vérifiez le texte alternatif et les dimensions des espaces réservés. Le code de vérification ne doit pas dépendre d’une image.	Le nom de l’entreprise, l’objet de l’action, la durée de validité et les liens nécessaires doivent être présents directement sous forme de texte.	Même sans logo ni image décorative, l’utilisateur comprend ce qui s’est passé et quelle est la prochaine étape.
Lisibilité en mode sombre	Testez séparément l’arrière-plan, le texte, les logos transparents et le contour des boutons en mode sombre dans les clients de messagerie ciblés.	Évitez les consignes qui dépendent d’une couleur, comme « cliquez sur la zone verte » ; décrivez directement l’action à effectuer.	Le contraste des textes essentiels est suffisant. Une validation de l’aperçu clair dans le navigateur ne vaut pas validation du mode sombre.
Cohérence du contenu	Vérifiez le code, le montant, le numéro de reçu, la durée de validité et les paramètres des liens. Assurez-vous qu’aucun espace réservé du modèle ne subsiste.	Dans le MIME ou les journaux côté envoi, contrôlez la partie text/plain et confirmez qu’elle correspond aux mêmes données que le HTML pour ce test.	Les informations essentielles sont cohérentes dans les deux versions ; aucun ancien code, ancien montant ni lien d’un autre environnement ne doit apparaître.

Le résultat de l’aperçu peut différer de celui du client ciblé

Le corps HTML est rendu par Tempcase dans un environnement isolé, où les scripts dangereux et certains contenus interactifs sont limités. Les images, polices et styles distants peuvent également être affectés par les autorisations d’accès aux ressources, la protection contre le hotlinking et l’état du réseau ; les images intégrées en pièces jointes peuvent elles aussi ne pas s’afficher. Vérifiez d’abord que les ressources sont accessibles avant de conclure à un problème de modèle.

Les règles de rendu diffèrent entre les navigateurs et les clients de messagerie sur ordinateur et mobile. Avant toute mise en production, refaites les tests dans les clients que vous prenez réellement en charge. Pour vérifier le MIME texte brut, les en-têtes ou les pièces jointes, consultez également l’e-mail de test brut conservé par le système d’envoi. Cette page n’est ni un outil d’importation HTML ni un service de captures d’écran dans plusieurs clients.

Compte rendu de test

Conservez des éléments permettant à vos collègues de reproduire le test

Une capture montre le résultat ; la version et les données d’entrée permettent de le reproduire. Notez précisément quel e-mail vous avez reçu et ne présentez pas une seule réception réussie comme une validation de tous les scénarios.

Exemple de compte rendu anonymisé

Vérification d’inscription / case-018

Résultat : nouveau test après modification

Version du modèle: signup-otp v2.4.1
Environnement et langue: Préproduction · zh · navigateur sur ordinateur
Heure du déclenchement: 2026-11-03 10:20:00 +08:00
Heure de réception: 2026-11-03 10:20:06 +08:00
Problème et éléments de preuve: Dans l’aperçu à 390px, le texte sur la durée de validité revient à la ligne et se retrouve près du code. Capture : case-018-narrow-redacted.png.
Prochain test: Ajuster l’espacement du texte explicatif, puis déclencher un nouveau test avec une nouvelle adresse. Comparer le HTML et le texte brut, et tester également le client de messagerie mobile ciblé.

Les heures ci-dessus ne sont qu’un exemple de format de compte rendu et ne garantissent aucun délai de réception. Avant de partager une capture, masquez les codes, les jetons de réinitialisation, les adresses de réception complètes et les données client. Ne publiez jamais d’identifiants utilisables dans un ticket public.

Vérification d’inscription

Vérifiez surtout que le code correspond au compte, que sa durée de validité est clairement indiquée et que le comportement des anciens codes après un nouvel envoi est défini. L’affichage correct de l’e-mail ne suffit pas : vérifiez aussi les règles côté serveur dans l’application de test.

Réinitialisation du mot de passe

Vérifiez l’objet de la réinitialisation, l’environnement du lien, sa durée de validité et les consignes en cas d’action non sollicitée. Pour vérifier l’expiration du lien et son invalidation après utilisation, testez dans l’application autorisée ; l’apparence du bouton ne suffit pas.

Notification de transaction

Vérifiez le montant, la devise, l’heure, le numéro et le détail des articles. Refaites le test avec des noms de produits longs, plusieurs articles et des données dans différentes langues. Ne vous fiez pas à un reçu très court pour juger de la stabilité de la mise en page.

Questions fréquentes

Commencez par identifier le niveau concerné

La réception, le contenu, la mise en page et la validation métier sont quatre résultats différents. Consignez-les séparément pour résoudre le problème dans la bonne direction.

Ouvrir le diagnostic de réception des codes

L’e-mail n’arrive toujours pas : modifier le HTML peut-il résoudre le problème ?

Ne modifiez pas encore la mise en page du modèle. Vérifiez l’adresse de réception, sa durée de validité, la tâche d’envoi et les journaux d’envoi, puis suivez les étapes de dépannage de réception pour localiser le problème. Tant que le corps du message n’a pas été reçu, vous ne pouvez pas attribuer le problème à la mise en page.

Si l’affichage est correct dans le navigateur, peut-on mettre le modèle en production ?

Cela ne suffit pas à valider tous les clients. Cet aperçu sert uniquement à vérifier le contenu et la mise en page de base. Avant la mise en production, testez encore les retours à la ligne, le chargement des images et le mode sombre dans les clients de messagerie ciblés sur ordinateur et mobile.

Pourquoi vois-je le HTML sans pouvoir le comparer au texte brut ?

Le système d’envoi n’a peut-être pas généré de partie text/plain, ou le mode d’affichage actuel ne la présente pas. Consulter le code source HTML ne revient pas à consulter le texte brut ; vérifiez dans le MIME brut côté envoi que les deux versions sont bien fournies.

Les exemples Netflix et Uber peuvent-ils servir de vrais modèles ?

Non. Ce sont des exemples originaux de Tempcase, sans lien avec les marques citées. Ils illustrent uniquement comment vérifier un bloc de code et le détail d’un reçu. Ils ne donnent pas accès à de vrais comptes et ne doivent pas servir à usurper l’identité d’une marque dans un e-mail.

Mon compte de test doit encore recevoir des e-mails le lendemain. Quelle solution choisir ?

Utilisez un alias de transfert permanent ou une adresse durable que vous êtes autorisé à utiliser. Une adresse temporaire est valide au maximum 24 heures et ne peut pas être récupérée après expiration ; ne l’utilisez pas pour un compte officiel qui doit rester accessible à long terme.

Appliquez cette méthode au prochain e-mail

Commencez avec une adresse dédiée

Pour un test ponctuel, utilisez une boîte de réception temporaire ; pour les tests de régression sur plusieurs jours, utilisez un alias de transfert. Recevez d’abord un véritable e-mail avant de décider quoi modifier dans le modèle.

Ouvrir la boîte de réception Se connecter au transfert permanent

Testez une inscription,vérifiez l’e-mail transactionnel de bout en bout