Vérification d’un code : consignez trois horaires

Définissez d’abord le périmètre : testez uniquement les parcours autorisés

Effectuez des tests uniquement sur des parcours d’inscription ou de connexion qui vous appartiennent ou pour lesquels vous avez reçu une autorisation explicite. Privilégiez un environnement de test et des comptes dédiés. Ne créez pas de comptes en masse, ne contournez pas les limites de fréquence et n’utilisez pas d’adresse temporaire pour éviter les règles du site. Si le service refuse explicitement les adresses jetables, consignez cette restriction au lieu d’essayer de la contourner avec d’autres adresses.

Commencez par formuler la question à examiner : s’agit-il de vérifier si le message arrive, ou de comparer la validité de l’ancien code après un renvoi ? Ne modifiez qu’un seul paramètre par essai. Une adresse temporaire permet d’observer le résultat côté utilisateur, mais ne remplace ni les journaux de file d’attente du service d’envoi, ni les accusés SMTP, ni les journaux de vérification côté serveur.

Que consigner pour chacun des trois horaires

Utilisez l’horloge d’un même appareil et consignez la date, le fuseau horaire et les secondes. Si vous utilisez plusieurs appareils, vérifiez d’abord que leurs horloges sont synchronisées. T1, T2 et T3 sont des repères de consignation ; ils ne signifient pas que tous les traitements en arrière-plan se déroulent dans cet ordre.

T1 Demande envoyée

Notez l’heure à laquelle vous cliquez sur « Envoyer », puis indiquez si la page a accepté la demande. Un clic confirmé ne signifie pas que le serveur a déjà transmis le message au système de messagerie. Si vous êtes autorisé à consulter l’interface, vous pouvez aussi noter l’heure de réponse et l’identifiant de la requête.

T2 Première apparition de l’e-mail

Notez l’heure à laquelle vous voyez le message pour la première fois dans la boîte de réception. Ne vous fiez pas à la date indiquée dans le corps du message ni au champ Date de l’expéditeur : ces informations ne correspondent pas nécessairement à l’heure d’arrivée côté réception.

T3 Limite de validité du code

Consignez séparément la durée annoncée par l’expéditeur et le résultat réel de la soumission. Si vous ignorez si le décompte commence à la demande, à la génération ou à l’envoi, indiquez « point de départ non confirmé » au lieu de le supposer.

T2 moins T1 correspond au « délai avant première apparition côté utilisateur », et non au « temps d’acheminement SMTP ». De même, un message d’expiration prouve généralement seulement que cette tentative n’a pas été acceptée ; il ne permet pas de déterminer à la seconde près quand le code a expiré.

Préparation : une session, une adresse complète

Ouvrez la boîte de réception temporaire puis copiez l’adresse complète générée. Vérifiez qu’il n’y a ni espace superflu ni caractère manquant dans le formulaire d’inscription. Les messages Microsoft et Uber affichés sur la page d’accueil sont des exemples, pas le résultat de votre test ; ne les comptabilisez pas dans le suivi de réception.

• Gardez un seul onglet d’inscription ouvert et appelez cette session A. Ne lancez pas la même opération simultanément sur votre téléphone.
• Vérifiez le temps restant sur l’adresse temporaire et prévoyez une marge pour l’attente, la vérification et la consignation des résultats.
• Désactivez le remplissage automatique ou les nouvelles tentatives susceptibles de modifier les conditions du test, et fixez à l’avance une durée d’attente maximale.
• Consignez l’environnement, le navigateur et l’objectif de l’essai. Ne stockez pas les codes complets ni les identifiants d’accès dans un document partagé.

Une nouvelle boîte temporaire Fwdsky est valide 3 heures par défaut ; chaque prolongation réussie ajoute 3 heures. Fiez-vous au compte à rebours affiché. Cette durée correspond à la disponibilité de la boîte, pas à la validité du code envoyé par le site. Consultez d’abord le guide de gestion de la durée de validité pour vérifier si une adresse temporaire convient à votre test.

Premier essai : un seul envoi pour établir une référence

Attribuez l’identifiant A-R1 à la première demande. Cliquez une seule fois sur « Envoyer », puis notez T1 et le message affiché par la page. Si le message n’arrive pas, attendez selon le délai prévu au lieu de cliquer plusieurs fois. Lorsqu’il apparaît, consignez T2, l’objet et les éléments expurgés qui permettent de l’identifier. Soumettez ensuite le code sur la même page d’inscription et notez l’heure de soumission ainsi que le résultat tel qu’il est affiché.

Voici un exemple fictif de consignation. Toutes les heures sont celles d’une même journée, sur un même appareil, en heure de Pékin. Pour un test réel, indiquez vos propres données.

Cet essai permet de conclure : « Première apparition après 12 secondes, puis soumission acceptée. » Il ne permet pas d’affirmer : « Le serveur de messagerie a acheminé le message en exactement 12 secondes. » Pour tester la règle d’expiration, faites un autre essai. Un code déjà utilisé avec succès ne permet pas, à lui seul, de déterminer s’il expire.

Une vérification toutes les sept secondes n’est pas un chronomètre d’acheminement

La boîte de réception Fwdsky vérifie automatiquement les nouveaux messages toutes les 7 secondes. Si une vérification ne trouve aucun message et que la suivante en affiche un, le changement de visibilité a pu se produire entre les deux. La page seule ne permet pas de savoir à quelle seconde. Le temps de réponse, le délai de réaction humaine et la limitation des tâches en arrière-plan du navigateur ajoutent aussi une marge d’erreur.

Consignez également les actualisations manuelles

Si vous actualisez manuellement entre deux vérifications automatiques, notez l’heure de l’actualisation. Elle peut vous faire voir plus tôt un message déjà arrivé, mais n’accélère pas son acheminement par l’expéditeur. Ne comparez pas directement les écarts de quelques secondes entre un essai avec actualisation manuelle et un autre où vous avez attendu la vérification automatique.

Formulation recommandée : « À 14:00:12, le message est apparu pour la première fois dans la page ; la vérification automatique était activée. » Évitez : « Le message a été remis à SMTP exactement à 14:00:12. »

Pour tester précisément l’acheminement d’un code, associez, dans un environnement autorisé, l’identifiant de la demande, l’heure de mise en file, les données d’envoi et les journaux de réception, puis vérifiez la synchronisation des horloges de tous les systèmes. La page côté utilisateur ne fournit qu’une partie des éléments de preuve.

Deuxième essai : testez ensuite la règle de renvoi

Conservez d’abord les conclusions de référence, puis ouvrez un nouveau relevé pour le deuxième essai. Appelez la première demande B-R1 et le renvoi B-R2, après avoir respecté le délai imposé par l’expéditeur. Consignez séparément l’heure du clic, de la prise en compte et de la première apparition. Après un renvoi, le code peut changer ou rester le même ; le seul fait que les chiffres diffèrent ou non ne prouve pas qu’un nouvel envoi a eu lieu.

Associez les codes aux demandes, pas à leur position dans la liste

Ne partez pas du principe que le message en tête de liste correspond toujours à la dernière demande. Des traitements asynchrones peuvent se terminer dans le désordre. Si le message ne contient ni identifiant de demande ni autre élément fiable permettant de le rattacher, notez « attribution non confirmée ». Si vous avez accès aux journaux, utilisez-les pour établir le lien ; sans preuve, ne tirez pas de conclusion.

• Vérifiez d’abord les règles du service : le renvoi invalide-t-il immédiatement l’ancien code, ou les deux restent-ils valides pendant un court moment ?
• Pour vérifier l’ancien et le nouveau code, tenez compte du fait qu’une validation réussie peut consommer le code ou mettre fin à la vérification. Si nécessaire, séparez les essais.
• Consignez chaque résultat de vérification et respectez les limites de tentatives. N’essayez pas plusieurs codes à répétition pour déterminer la seconde exacte de leur expiration.

Si la page renvoie seulement « invalide ou expiré », conservez cette catégorie combinée. La cause peut être un délai dépassé, une utilisation antérieure, un remplacement après renvoi ou une session différente. N’écrivez pas directement que « le nouveau code a remplacé l’ancien ».

Traitez séparément les onglets multiples et les messages tardifs

Un onglet A peut lancer une inscription tandis qu’un onglet B lance une connexion. Même avec la même adresse e-mail, il peut s’agir de vérifications distinctes. Distinguez la page, l’usage et la session dans vos notes avant d’associer un message. Ne saisissez pas le code de B dans A pour ensuite attribuer l’échec à un problème de réception.

Si un ancien message arrive après la fin d’un essai, indiquez « arrivé en retard, rattaché à l’essai précédent ou attribution à confirmer ». Conservez l’heure de la demande initiale sans remettre le compteur à zéro. Si l’isolation le permet, vous pouvez utiliser une autre adresse pour le nouvel essai. Mais le changement d’adresse détruira l’ancienne boîte : vous ne pourrez plus y observer les messages reçus ultérieurement pour l’ancienne demande.

Une session partagée dans le navigateur peut également faire interagir les onglets. Si vous avez besoin de sessions indépendantes, utilisez une configuration de test isolée et autorisée, puis consignez ce changement d’environnement. Ouvrir un nouvel onglet ne crée pas, à lui seul, une session indépendante.

Classez l’échec avant de décider de la suite

« Je ne reçois rien » n’est pas une conclusion assez précise. Indiquez à quelle étape l’échec s’est produit pour éviter d’actualiser sans cesse au mauvais endroit.

La durée de validité de la boîte temporaire, celle du code et le délai avant un nouveau renvoi sont trois compteurs différents. Prolonger la boîte ne prolonge pas un code déjà envoyé ; actualiser la boîte de réception ne rend pas valide un code expiré.

À la fin, conservez les conclusions, pas les secrets

Conservez une version expurgée de l’environnement, des identifiants de demande, des horaires, du mode d’attente et des catégories de résultat. Masquez l’adresse complète, le code, les identifiants de session et le contenu privé sur les captures d’écran. Ne partagez pas le jeton d’accès à la boîte de réception dans un ticket, un chat ou un document partagé. Supprimer les messages de test ne supprime pas le compte tiers créé.

Une fois le test terminé, supprimez les messages, puis supprimez le compte de test ou remplacez son adresse par une adresse pérenne en suivant la procédure du service testé. N’utilisez pas une adresse temporaire pour la récupération de mot de passe, les remboursements ou les alertes de sécurité. Effacer les données du navigateur ne supprime pas celles du serveur ; consultez la politique de confidentialité pour connaître les limites exactes.

Étape suivante : choisissez une adresse adaptée à votre usage

Pour vérifier un seul e-mail d’inscription, vous pouvez retourner à la boîte de réception pour le prochain essai. Pour suivre des notifications, une procédure de récupération ou des e-mails de commande ultérieurs, utilisez une boîte durable que vous contrôlez ou créez une adresse de transfert après vous être connecté. Les alias transfèrent les messages entrants vers votre véritable boîte e-mail ; vous devez toutefois bien gérer l’accès au compte et l’état des alias.

Vous hésitez encore ? Consultez d’abord la différence entre une adresse e-mail temporaire et un alias . Le but de la méthode n’est pas de terminer le test plus vite, mais de permettre à la personne qui le vérifiera ensuite de savoir ce que vous avez observé et ce qui reste sans preuve.