Préparez un e-mail représentatif pour l’inscription, la connexion, la récupération de compte et les notifications, puis notez les conditions de déclenchement et le délai de réception attendu.
Validation avant mise en ligne · 12 points de contrôle
Checklist de test des e-mails : de l’envoi à l’utilisation
Ne vérifiez pas seulement la réception. Avec une boîte de test vierge, contrôlez l’identité, le contenu, les interactions et les solutions de repli, puis transmettez les preuves au responsable de la mise en ligne.
Vérifiez au moins l’affichage sur ordinateur et sur un mobile de 390 px de large, afin de vous assurer que les objets longs, les boutons et les codes ne sont pas coupés.
Cliquez sur les liens, copiez les codes et essayez un code expiré pour confirmer la cohérence de la destination, du statut et du message d’erreur.
Enregistrez les heures d’envoi et de réception, les captures d’écran et les identifiants de bugs, plutôt que d’écrire simplement « e-mail conforme ».
01 · Identité de l’expéditeur
Vérifiez le nom affiché, les champs From et Reply-To ainsi que le domaine attendu. Assurez-vous que le nom de la marque ne comporte ni suffixe d’environnement ni faute. Répondez à un e-mail de test pour confirmer que la réponse n’aboutit pas à une adresse non gérée.
Vérifiez si l’identité de l’expéditeur peut faire croire à un e-mail d’hameçonnage. Si différents types d’e-mails utilisent des sous-domaines distincts, indiquez clairement leur correspondance dans le rapport de test.
02 · Objet et texte d’aperçu
L’objet doit préciser l’action et le contexte, sans révéler le code complet, des informations sensibles de commande ni le nom d’un environnement interne. Le texte d’aperçu doit compléter l’objet, pas répéter la première ligne du message.
Testez séparément un objet court et un objet localisé très long. Vérifiez qu’après tronquage par le client, l’usage de l’e-mail reste identifiable.
03 · Codes de vérification
Vérifiez le nombre de caractères, le regroupement, la facilité de copie, la durée de validité et la règle d’utilisation unique. Après deux demandes successives, confirmez que le traitement de l’ancien et du nouveau code correspond à la conception prévue.
Saisissez un code incorrect, expiré ou contenant des espaces. Le message d’erreur doit indiquer le problème sans révéler l’état du compte.
04 · Liens et boutons
Le bouton principal doit renvoyer vers le bon domaine, le bon chemin et la bonne langue, sans nom d’hôte de test. Le focus clavier, le libellé du bouton et le titre de la page cible doivent indiquer ensemble l’étape suivante.
Vérifiez les liens de désinscription, de préférences et en version texte. Après expiration d’un lien, proposez une solution pour continuer plutôt qu’une page d’erreur vide.
05 · Structure HTML
Après désactivation des images distantes, l’ordre de lecture, les textes alternatifs et les actions principales doivent rester compréhensibles. Vérifiez que les tableaux ne débordent pas sur petit écran et que les images décoratives ne sont pas annoncées plusieurs fois par les lecteurs d’écran.
Vérifiez que la taille de police, l’interligne et le contraste permettent une lecture confortable. N’utilisez pas une image pour transmettre un code, un montant ou une information essentielle unique.
06 · Version texte
La version texte doit contenir les mêmes informations essentielles que le HTML, les liens complets et les moyens de contacter l’assistance. Après suppression des paramètres de suivi, les liens doivent toujours mener vers une destination valide.
Vérifiez que les retours à la ligne, les listes et les URL longues restent lisibles. En l’absence de version texte, signalez un risque de mise en ligne au lieu de valider silencieusement.
07 · Champs personnalisés
Testez un nom normal, un nom vide, un nom très long et des caractères non latins, afin de vérifier qu’aucune variable de modèle ni ponctuation superflue n’apparaît. Les montants, dates et fuseaux horaires doivent être formatés selon le contexte du destinataire.
Si un champ est absent, le texte de repli doit rester naturel et ne pas révéler le nom d’une variable interne. N’utilisez pas de véritables données sensibles de clients dans les échantillons de production.
08 · Délai de réception
Notez l’heure du déclenchement et celle de la réception au lieu de juger la rapidité au ressenti. Pour les e-mails contenant un code, définissez le seuil acceptable en fonction de sa durée de validité.
En cas de retard, distinguez d’abord les quatre étapes : file d’attente de l’application, acceptation par le prestataire d’envoi, filtrage par la boîte cible et actualisation par l’utilisateur. Décidez ensuite s’il faut renvoyer le message.
09 · Cohérence des statuts
Une seule action déclenchée par l’utilisateur ne doit pas produire plusieurs e-mails ; lorsque l’interface indique que le message est envoyé, le système doit également générer l’événement correspondant. Après un échec, une nouvelle tentative ne doit pas réutiliser un ancien lien ou code.
Vérifiez le statut entre plusieurs onglets et après actualisation. Un e-mail reçu avec succès ne doit pas laisser l’interface afficher « en attente ».
10 · Accessibilité
Parcourez les liens au clavier dans l’ordre de lecture et vérifiez que le focus est visible, que les noms des boutons sont explicites et que la hiérarchie des titres est cohérente. Dans l’e-mail, la couleur ne doit jamais être le seul moyen d’indiquer une réussite ou une erreur.
Utilisez un texte alternatif vide pour les images décoratives et une description concise pour les images informatives. Les animations doivent respecter la préférence de réduction des mouvements.
11 · Sécurité et confidentialité
Vérifiez que l’e-mail ne contient ni mot de passe, ni données de paiement complètes, ni clé de production, ni informations personnelles superflues. Les liens de récupération et de connexion doivent avoir une durée raisonnable et devenir invalides après utilisation.
Les adresses de test doivent servir uniquement à du contenu autorisé. Supprimez les échantillons à la fin et ne faites pas d’une adresse temporaire un point de récupération durable pour un compte important.
12 · Conclusion de mise en ligne
Classez le résultat en « validé », « validé avec risques » ou « mise en ligne bloquée », et joignez les étapes de reproduction à chaque échec. Précisez dans la conclusion le client, la taille d’écran, la langue et l’heure du test.
Après une correction, retester uniquement le point concerné ne suffit pas : vérifiez de nouveau tout le parcours, du déclenchement à la réception, à l’ouverture et à l’action.
Compte rendu minimal de mise en ligne
Conservez au minimum les champs suivants pour chaque validation, afin que le prochain collègue puisse reproduire le test au lieu de dépendre d’une conclusion orale.
| Échantillon | Déclenchement et réception | Client | Conclusion |
|---|---|---|---|
| Code d’inscription | Heure de déclenchement, heure de réception, durée de validité du code | Web sur ordinateur + mobile | Validé ou identifiant de bug |
| Récupération du mot de passe | Génération du lien, première utilisation, deuxième utilisation | HTML + texte brut | Destination et statut d’expiration |
| Modèle de notification | Combinaison de champs et fuseau horaire | Images activées / désactivées | Risques liés à la mise en page et au texte |
Prêt à commencer ? Revenez à la boîte de test ForwardTop et créez une nouvelle adresse pour repartir d’un échantillon vierge à chaque validation.