Après le renvoi d’un code,
le premier e-mail reçu est-il forcément valide ?

Relevez trois horaires distincts au lieu de vous fier à l’ordre des e-mails

En 2026, les processus d’inscription mettent souvent l’envoi des codes en file d’attente : la page indique que la demande a été acceptée, le serveur génère le code, puis le service de messagerie tente de le distribuer. La mention « envoyé » peut simplement signifier que la tâche a été créée, sans prouver que l’e-mail a atteint le serveur de réception. Une deuxième demande peut emprunter une file plus rapide : le nouveau code arrive alors avant l’ancien.

Pendant le test, notez au minimum trois horaires : l’heure locale du clic sur « Envoyer », celle de la première apparition de l’e-mail dans la boîte de réception et celle de la saisie du code. Si vous avez accès aux journaux du serveur, ajoutez l’heure d’émission du code et l’identifiant de la tâche d’envoi. Ne prenez pas la date indiquée dans le corps du message ou le champ Date pour l’heure de réception : ces informations sont généralement renseignées par l’expéditeur.

L’interrogation périodique du navigateur indique uniquement l’heure à laquelle la page a constaté l’arrivée du message pour la première fois. Sa précision dépend de l’intervalle d’interrogation, du réseau et du fait que la page soit au premier plan ou non. Elle permet de repérer un désordre à l’échelle de la minute, mais pas de surveiller une livraison à la milliseconde. Pour calculer précisément des indicateurs de niveau de service, utilisez les journaux d’envoi et de réception plutôt que d’essayer de déduire les horaires à partir de captures d’écran.

Envoyez une seule fois pour établir une référence reproductible

Commencez par ouvrir la boîte de réception de test, copiez l’adresse actuelle et vérifiez que sa durée de validité couvre toute la session de test. Utilisez cette adresse uniquement dans un environnement de test sur lequel vous êtes autorisé à intervenir ; ne l’associez pas à des actifs, à des comptes de production ni à une identité qui doit pouvoir être récupérée à long terme. L’expiration de l’adresse et celle du code sont indépendantes : prolonger la première ne prolonge pas la seconde.

1. Préparez un compte de test jamais utilisé et notez l’environnement, la version de la page et le fuseau horaire local.
2. Cliquez une seule fois sur « Envoyer ». Notez si la demande aboutit ; ne cliquez pas plusieurs fois pour tenter d’accélérer la réception.
3. Laissez la page de réception ouverte jusqu’à l’arrivée du véritable e-mail, puis vérifiez l’adresse destinataire, l’objet et l’usage indiqué dans le message.
4. Saisissez le code pendant sa durée de validité déclarée et consignez le résultat. Réessayez ensuite avec le même code pour vérifier s’il a déjà été consommé.

La deuxième saisie du même code doit-elle échouer ? Tout dépend des spécifications du produit. Un code destiné à une connexion ponctuelle devrait généralement expirer après une utilisation réussie, mais les testeurs ne doivent pas supposer que tous les produits fonctionnent ainsi. Vérifiez d’abord auprès de l’équipe d’authentification si la durée de validité commence à l’émission ou à l’envoi, si le code est consommé immédiatement après validation et si une seule adresse ne peut avoir qu’un code actif à la fois.

Si vous ne recevez déjà aucun e-mail à cette étape, retournez aux vérifications du déclenchement et de la livraison dans l’espace de test des inscriptions au lieu de commencer tout de suite les essais de renvoi. Sans scénario de référence concluant, il est facile de confondre « ancien code invalidé » et « e-mail jamais envoyé ».

Testez le renvoi en deux séries pour éviter de fausser les résultats

Une fois le délai d’attente écoulé, demandez le code B et identifiez les deux e-mails comme première et deuxième série. Si les deux contiennent le même code, ne concluez pas à un doublon sur la seule base de cette valeur : certains systèmes renvoient le même code tant qu’il est valide, d’autres en génèrent un nouveau à chaque demande. Appuyez-vous sur les identifiants de tâche, les journaux d’envoi et la conception du produit.

Si les spécifications précisent que le renvoi invalide immédiatement l’ancien code, effectuez deux tests indépendants. Au premier, demandez A puis B, saisissez A et consignez le refus. Au second, ouvrez une nouvelle session propre, redemandez A puis B et saisissez uniquement B pour confirmer que le nouveau code permet la validation. Ne consommez pas B avant de conclure que l’échec de A confirme le mécanisme de renvoi : A pourrait aussi être refusé parce que le défi a déjà pris fin.

• L’ancien code fonctionne encore après l’émission du nouveau : examinez le stockage et l’invalidation du défi actif, pas seulement la file d’e-mails.
• Le nouveau code échoue également : vérifiez l’identifiant du défi, la session, l’adresse de test et l’horloge, puis contrôlez l’expiration.
• L’e-mail arrive après l’expiration du code : demandez aux équipes messagerie et authentification d’analyser ensemble le délai entre l’émission et la livraison.
• Le renvoi est limité : respectez le délai d’attente et la fréquence autorisée ; ne contournez pas la limitation.

Testez aussi séparément les limites de validité, avec des codes distincts : pendant la période de validité, juste avant son expiration et après celle-ci. Évitez de multiplier les essais avec un même code au risque de déclencher un verrouillage. Le compte à rebours du client est indicatif ; seul le serveur détermine le résultat. L’avance ou le retard de l’horloge de l’appareil ne doit pas décider de la validité du code.

Distinguez les conflits entre onglets des e-mails reçus en double

Si un onglet envoie A et un autre B, chaque page peut utiliser un défi ou une session différente. L’échec de B dans le premier onglet ne prouve pas que les e-mails sont arrivés dans le désordre. Reproduisez d’abord le problème avec un seul onglet, puis testez-en deux en consignant séparément les actions et les résultats attendus pour chacun.

Si vous recevez deux e-mails identiques, distinguez au moins trois cas : la page a envoyé deux demandes, le serveur a réessayé la livraison ou l’interface de réception affiche le message deux fois. Si vous avez accès aux en-têtes bruts, comparez les Message-ID et associez-les aux journaux des tâches d’envoi. Ce n’est toutefois qu’un indice, pas une preuve irréfutable : un transfert ou le traitement par le fournisseur peut modifier les champs concernés.

La réception d’un seul e-mail ne prouve pas non plus que le système empêche les doublons. La deuxième tâche n’a peut-être pas encore été exécutée, ou le fournisseur de messagerie a pu fusionner les messages. Pour valider la protection contre les doublons, vérifiez les identifiants de requête et les enregistrements des tâches du système testé. La boîte temporaire sert à constater le résultat final, pas à remplacer l’audit des opérations en arrière-plan.

Consignez vos observations pour qu’une autre personne puisse reproduire le test

Un rapport exploitable doit indiquer la version de l’environnement, un identifiant de compte anonymisé, la durée de validité de l’adresse, l’heure de la demande de code, celle de la première réception observée, l’heure de saisie du code et le résultat affiché. Remplacez les codes complets par A et B ; pour faire le lien avec les journaux, indiquez l’ID de la tâche. Ne publiez jamais dans un ticket un code encore valide. Si une capture d’écran contient un lien de vérification, masquez également son jeton avant de la partager.

Formulez des conclusions précises et limitées. « Après la deuxième demande, le premier code a encore été accepté dans la même session » est plus exploitable que « les codes ne sont pas sécurisés ». « La page de réception a constaté l’arrivée de l’e-mail après 12 secondes » est plus exact que « le service de messagerie a mis 12 secondes », car vous n’avez pas mesuré toutes les étapes intermédiaires.

Après avoir vérifié l’ordre d’arrivée, examinez aussi le contenu du message. L’objet indique-t-il clairement son utilité ? Le corps précise-t-il la durée de validité ? Sur mobile, les chiffres qui se ressemblent sont-ils faciles à distinguer ? Poursuivez avec le contrôle du contenu et du texte brut des e-mails de notification pour vérifier séparément que le message est bien arrivé et que l’utilisateur peut l’utiliser correctement. Si un terme vous semble incertain, consultez le glossaire de la réception des e-mails.