Un e-mail de vérification ne se résume pas à sa réception

Commencez par cartographier le cycle de vie du code

Dès que l’utilisateur clique sur Envoyer, le système crée un code, lui associe une durée de validité, le met en file d’attente, puis attend sa validation. Voir l’e-mail arriver prouve seulement qu’une étape a réussi : cela ne confirme pas que le code est correctement lié au compte, à sa période de validité et aux règles d’utilisation unique.

Le compte rendu de test doit au minimum inclure l’adresse cible, l’heure du déclenchement, l’ID de la tâche, l’heure de réception et le résultat de la validation. Utilisez une adresse de test isolée plutôt qu’une boîte personnelle conservée sur le long terme.

Vérifiez la cohérence du parcours réussi

Le code à six chiffres de l’e-mail doit correspondre à la session en cours et le texte indiquant sa durée de validité doit respecter les règles du serveur. Après un copier-coller, seuls des chiffres seuls doivent être acceptés, sans fausse détection due aux espaces ou au formatage de l’interface.

Après une validation réussie, le parcours doit mener à la bonne page et ne plus afficher la notification persistante « Code de vérification envoyé ». Si le même code est réutilisé, le produit doit le refuser conformément à ses règles ou conserver l’état déjà terminé, sans créer une seconde session.

Un renvoi ne consiste pas simplement à envoyer un autre e-mail

Le bouton de renvoi doit partager le même délai d’attente que le premier envoi, rester désactivé pendant le compte à rebours et afficher le nombre de secondes restantes. Si l’utilisateur revient modifier son adresse, les codes de l’ancienne et de la nouvelle adresse ne doivent pas être interchangeables.

Précisez clairement si l’ancien code devient immédiatement invalide après l’émission du nouveau. Lors du test, notez l’ordre de réception et la valeur des codes pour les deux e-mails, afin qu’un retard réseau ne fasse pas arriver le second avant le premier.

Comment tester les limites d’expiration

Le serveur doit faire foi pour déterminer l’expiration ; ne simulez pas ce cas en modifiant l’horloge de l’appareil. Envoyez successivement le code au milieu de sa période de validité, près de la limite, puis après celle-ci, et vérifiez que les messages distinguent clairement un code invalide, expiré ou bloqué pour fréquence excessive.

Si l’e-mail arrive alors que le code est presque expiré, comparez les heures du déclenchement, de la mise en file, de l’envoi et de la réception. Vous pourrez ainsi déterminer si la durée de validité est trop courte ou si la file d’envoi présente un retard anormal.

Limitation de débit et adresse vide

Une adresse vide ou mal formée doit bloquer le parcours dès la première étape et ne doit pas déclencher l’envoi d’un code au serveur. Lorsque le nombre de demandes atteint la limite, l’interface doit fournir un message en français et proposer une attente compréhensible.

Après la fin de la limitation, un nouvel envoi ne doit pas réutiliser un ancien jeton de connexion ni accéder directement à l’étape du code à cause de traces de la session précédente. L’adresse peut être restaurée depuis la session, mais le parcours doit repartir du point de départ de l’authentification publique.

Conservez un minimum de preuves de test

Pour documenter un bug, conservez uniquement la version du modèle, l’ID de la tâche, l’heure, l’adresse masquée et le message d’erreur. Un code valide, un lien de connexion complet ou des données d’identité réelles ne doivent pas rester durablement dans des captures d’écran ou des documents partagés.

Après la correction, recommencez le test avec une nouvelle adresse, un nouvel identifiant et un nouveau code afin d’éviter d’ouvrir par erreur un ancien e-mail. Vérifiez les quatre résultats — succès, ancien code, expiration et limitation de débit — avant de fermer l’accès de test.