Test des renvois de codes OTP :
relier chaque e-mail à sa demande

Pourquoi les tests de régression automatisés confondent encore deux tentatives en 2026

Les scripts automatisés suivent souvent cette séquence : « demander un code → attendre l’e-mail → récupérer le plus récent → le soumettre ». Un test ponctuel réussi ne garantit pas que les renvois successifs fonctionneront : le premier e-mail est encore dans la file lorsque la deuxième demande aboutit ; deux fenêtres utilisent le même compte, mais le script n’enregistre que l’heure du dernier clic.

Dans ce cas, le dernier e-mail de la boîte peut correspondre à une demande antérieure. Le récupérer uniquement selon son objet, son statut non lu ou son ordre d’arrivée peut faire passer un retard de livraison pour une erreur de code. Il peut aussi arriver qu’un code erroné soit accepté par hasard, masquant ainsi un défaut. Pour tester les e-mails d’inscription, commencez par établir les correspondances au lieu d’écrire une expression régulière qui extrait six chiffres.

Définir les règles de renvoi au lieu de les déduire de la boîte de réception

Avant de tester les renvois de codes OTP, demandez aux équipes produit et backend de confirmer des règles précises : le renvoi réutilise-t-il un code encore valide ou en génère-t-il un nouveau ? À quel moment l’ancien code est-il invalidé ? La durée de validité commence-t-elle à la première émission ou à la plus récente ? Les règles s’appliquent-elles au compte, à l’usage ou à une session de vérification ?

Consignez la version des règles dans le cas de test. Si elles ne sont pas encore clairement définies, notez les points à confirmer au lieu de laisser l’assertion automatisée décider à la place de l’équipe produit. Les exemples de reproduction ci-dessous partent explicitement de la règle suivante : « dès que l’émission du nouveau code réussit, l’ancien est immédiatement invalidé ».

Un cas par test : l’adresse n’est qu’une partie du contexte

Dans la boîte de réception temporaire copiez une adresse distincte et attribuez un identifiant à ce test, par exemple case-r17. Conservez cette adresse pour le premier envoi et les renvois de ce même test. Notez la version de préproduction, l’identifiant du compte, l’usage de la vérification et l’identifiant de session. Ne changez pas d’adresse à chaque clic sur « Renvoyer » : vous transformeriez un renvoi pour le même compte en première demande d’un nouveau compte.

Pour chaque demande, consignez séparément l’ID de la requête métier, le résultat de la réponse et l’ID d’événement généré par le service d’envoi. Une réponse positive de l’API métier peut seulement indiquer que la tâche a été mise en file d’attente. Si la tâche asynchrone n’a pas encore créé d’événement d’envoi, notez « à rapprocher » et complétez l’information plus tard. En cas de limitation de débit ou de rejet, ne vous attendez généralement pas à recevoir un nouvel e-mail ; référez-vous au contrat de l’API.

L’ID d’enregistrement d’e-mail de Tempcase appartient au système de réception et ne correspond pas automatiquement à l’ID de la requête métier. Si les détails de réception n’affichent ni les en-têtes de l’e-mail ni de champ de rapprochement, complétez les données à l’aide des journaux d’envoi, d’un marqueur de test contrôlé ou des outils d’observabilité de l’environnement de test. Ne faites pas de rapprochement arbitraire sur la seule proximité des horaires.

Créez un tableau de suivi en cinq colonnes pour relier chaque e-mail à son origine

Les cinq colonnes ci-dessous constituent le suivi minimal. Notez en tête du compte rendu le compte, l’environnement, la version des règles et la chronologie. Si une demande déclenche plusieurs tentatives d’envoi, conservez une ligne par tentative et indiquez les liens entre les relances au lieu d’écraser les anciens événements.

Pour chaque « événement d’envoi », précisez aussi l’étape atteinte : mise en file, transmission au service d’envoi, acceptation par le serveur distant ou rejet. Ne vous contentez pas de la mention vague « distribué ». L’ID d’un e-mail reçu peut aider à le retrouver, mais ne remplace pas le résultat de l’API de validation métier.

Renvois successifs, deux fenêtres et retard de file : que démontre chaque test ?

Renvois successifs : vérifier les règles et les limites de débit

Envoyez R1 et R2 en respectant l’intervalle de renvoi autorisé, puis consignez chaque réponse. Testez séparément les clics pendant la période d’attente imposée. Vérifiez qu’un refus n’a réellement créé aucune nouvelle tâche et que le nouveau délai de validité après renvoi correspond aux règles convenues. Ne multipliez pas les requêtes pour provoquer une surcharge et ne contournez pas les limites de débit.

Deux fenêtres : vérifier la portée de l’état

Dans deux fenêtres, utilisez le même compte de test et déclenchez les demandes dans un ordre défini, en notant l’identifiant de session de chacune. Vérifiez si l’invalidation s’applique aussi d’une fenêtre à l’autre. L’ancien message toujours affiché dans une fenêtre ne signifie pas que le serveur accepte encore l’ancien code ; inversement, une page mise à jour ne prouve pas que le serveur l’a invalidé.

Retard dans la file : vérifier le résultat métier en cas de désordre d’arrivée

Dans un environnement de test autorisé uniquement, retardez la livraison de R1 au moyen d’une file contrôlable ou d’une injection de panne afin que R2 arrive en premier. Consignez le point d’injection et la durée du retard. Ce test vérifie le respect des règles de validation en cas de désordre d’arrivée ; il ne mesure pas les délais de livraison sur un réseau réel. Ne modifiez pas les files de production.

L’ordre des e-mails ne correspond pas forcément à celui des demandes

L’ordre des demandes, des émissions, du traitement des tâches et de la réception peut varier. L’en-tête Date de l’e-mail est également généré par le système d’envoi et ne peut pas être considéré directement comme l’heure de réception. Pour repérer des codes OTP arrivés dans le désordre, privilégiez les liens entre événements qui peuvent être retracés plutôt que le seul e-mail le plus récent.

Dans un modèle que vous contrôlez, vous pouvez ajouter un identifiant de suivi de test sans donnée secrète, ou consigner dans les journaux la correspondance entre l’ID de la demande et le Message-ID de l’e-mail. Le code OTP lui-même ne peut pas servir de clé de rapprochement : le système peut réutiliser un même code et des demandes différentes peuvent produire des chiffres identiques. En l’absence de preuve permettant le rapprochement, indiquez « demande d’origine impossible à confirmer ».

Vérifier l’invalidation de l’ancien code côté métier

Vérifiez séparément ces trois points : l’e-mail est-il arrivé dans la boîte de réception ? Le code OTP a-t-il été accepté par le système métier ? La réussite de l’authentification a-t-elle créé la bonne session ou le bon état métier ? Recevoir un e-mail ne signifie pas que le code est valide ; une réponse positive de l’API de vérification ne garantit pas non plus que la connexion est terminée.

Pour vérifier l’ancien code, après confirmation de l’émission de R2, soumettez le code associé à R1 et consignez le type d’erreur métier ainsi que l’état du défi de vérification. Testez séparément la validité du nouveau code et sa réutilisation éventuelle. Une réussite avec le nouveau code peut consommer l’ensemble du défi, ce qui fera ensuite échouer l’ancien code et risque de masquer une invalidation défaillante lors du renvoi.

Rétablissez les mêmes conditions initiales pour chaque branche afin de ne pas dépasser le nombre de tentatives autorisé. Consignez uniquement « accepté » ou « refusé » ainsi que la catégorie d’erreur stable. N’incluez jamais le code OTP complet dans les rapports d’assertion, les noms de captures d’écran ou les journaux d’intégration continue.

Preuves temporelles : uniformiser le format sans perdre la source

Nous recommandons le format ISO 8601 avec fuseau horaire, puis une conversion uniforme en UTC pour la synthèse, tout en conservant la valeur d’origine et sa source. Distinguez les noms des champs, par exemple « heure d’émission par le service métier », « heure d’acceptation par le service d’envoi », « heure d’enregistrement par le service de réception » et « heure observée dans le navigateur ». Un format d’affichage identique ne signifie pas que les horloges des machines sont synchronisées.

• Pour mesurer une durée au sein d’un même processus, utilisez une horloge monotone et conservez aussi une heure civile de référence.
• Avant de comparer des services, vérifiez leur synchronisation horaire. Sans estimation fiable du décalage, ne soustrayez pas les heures pour annoncer un délai précis.
• L’heure à laquelle une interrogation périodique détecte l’e-mail pour la première fois est une heure d’observation. Si la page vérifie la boîte toutes les quelques secondes, il existe une fenêtre d’incertitude.
• L’heure indiquée dans l’en-tête de l’e-mail n’est qu’un indice ; elle ne remplace pas l’heure d’émission, de mise en file ou de validation métier.

Si vous savez seulement que l’e-mail était absent lors d’une vérification et présent à la suivante, consignez cet intervalle. Mieux vaut signaler honnêtement ce qui n’a pas pu être mesuré que d’annoncer une précision à la milliseconde sans source fiable.

Exemple de reproduction : le deuxième e-mail arrive avant le premier

L’exemple contrôlé ci-dessous ne décrit aucun incident survenu chez Tempcase ou dans un système métier particulier. La règle attendue est la suivante : pour un même défi de vérification, dès que le nouveau code de R2 est émis, l’ancien code de R1 est immédiatement invalidé.

1. Créez un défi de vérification de test et envoyez R1. Notez req-a → evt-a puis retardez sa livraison dans la file de test.
2. Une fois le renvoi autorisé, envoyez R2 et vérifiez que le nouveau code a été émis. Notez req-b → evt-b.
3. Observez d’abord mail-b, puis, après avoir supprimé le retard, observez mail-a; identifiez les deux e-mails grâce à leurs identifiants de suivi.
4. Soumettez l’ancien code A alors que le défi n’a pas encore été consommé avec succès. S’il est accepté, consignez la réponse de validation et l’état du défi, puis arrêtez immédiatement cette branche.

Si seul le premier e-mail arrive en retard et que l’ancien code est correctement refusé, ne qualifiez pas directement le désordre d’arrivée de défaut d’authentification. Une meilleure présentation de l’e-mail ou une amélioration du parcours dans la page peuvent être nécessaires, mais il s’agit d’un problème différent d’une défaillance des règles de sécurité.

Transmettez des preuves anonymisées, pas le code OTP complet

Le dossier transmis doit permettre à un collègue de reproduire le problème étape par étape, sans utiliser vos identifiants. Vous pouvez vous appuyer sur la liste ci-dessous ; remplacez le compte par un identifiant fictif et traitez les véritables adresses et identifiants de suivi selon la classification des données de votre équipe.

Ne faites jamais figurer le code OTP complet, les jetons de connexion, les cookies, les liens d’authentification ou les jetons d’accès à la boîte temporaire dans un rapport partagé. Masquez les informations secrètes dans le corps des e-mails sur les captures d’écran et vérifiez la barre d’adresse ainsi que les outils de développement dans les enregistrements vidéo. Évitez également de conserver un code OTP court sous forme de hachage ordinaire : le nombre de valeurs possibles est trop faible et facilite leur énumération. Utilisez plutôt des identifiants sans lien avec le code, comme A ou B.

Quand changer d’adresse et quand conserver le même compte

À la fin d’un test, ou pour vérifier le parcours d’une nouvelle inscription, changez d’adresse afin d’isoler les e-mails résiduels. Pour tester les renvois, deux fenêtres, les limites de débit ou l’invalidation d’un ancien code sur le même compte, gardez la même adresse et le même contexte ; autrement, les conditions du test auront changé.

Par défaut, les adresses temporaires Tempcase sont valides 3 heures, avec possibilité de prolonger leur durée jusqu’à 24 heures par adresse. Chaque demande de prolongation dans la plateforme ajoute 3 heures, dans la limite maximale. Une fois les e-mails expirés, ils sont irrécupérables : ne traitez pas la boîte de réception comme une archive de preuves. Pour conserver plusieurs jours un point de réception associé à un compte, vous pouvez créer un alias à l’aide de l’accès à la connexion par transfert longue durée; l’alias ne fait que transférer les e-mails reçus et ne remplace ni les journaux métier ni une conservation des preuves à durée illimitée.

Prochain test : commencez par vérifier les correspondances

Pour une première mise en place, inutile de couvrir toutes les anomalies d’un coup. Commencez par un envoi normal dont vous pouvez établir le suivi, ajoutez un renvoi, puis provoquez un désordre d’arrivée contrôlé. Si vous ne pouvez même pas confirmer l’envoi de l’e-mail, commencez par vérifier les preuves d’envoi et de réception avec le diagnostic de réception des codes OTP; une fois l’e-mail reçu, vérifiez sa mise en page, puis consultez l’outil d’aperçu des modèles d’e-mail.