Heure du déclenchement métier
Moment où l’utilisateur agit ou où le système déclenche un événement. Il permet de vérifier que le produit crée rapidement la tâche d’envoi.
La sémantique temporelle des e-mails
Un même e-mail peut avoir quatre heures différentes
L’heure du déclenchement, de la mise en file, de la réception et de l’affichage ne désigne pas le même événement. Harmonisez d’abord le fuseau et la définition de chaque événement avant de conclure qu’un code est en retard ou expiré.
10:00:00 DéclenchementL’utilisateur envoie le formulaire de connexion et l’application crée la tâche d’envoi. C’est l’heure de l’action métier.
10:00:02 Mise en fileLa tâche e-mail entre dans la file d’envoi. L’écart entre les deux heures reflète la liaison entre l’application et la file.
10:00:08 RéceptionLe serveur destinataire accepte l’e-mail. L’écart depuis la mise en file correspond davantage au délai de transmission.
18:00:08 AffichageLe navigateur affiche l’heure locale en UTC+8 ; elle peut correspondre exactement à 10:00:08 UTC.
Clarifier d’abord le sens
Ne soustrayez pas directement les heures affichées
Deux appareils qui affichent des heures différentes n’indiquent pas forcément un retard de livraison. Convertissez d’abord chaque heure dans le même fuseau ou vers le même horodatage.
Date dans les en-têtes de l’e-mail
Elle est généralement inscrite par le système d’envoi et peut dépendre de l’horloge du serveur, de la file et de la configuration. Elle ne suffit pas, à elle seule, comme preuve de réception.
Heure de réception
Moment enregistré par le système destinataire lors de l’acceptation. Il mesure mieux l’arrivée réelle, à condition de préciser le fuseau utilisé.
Heure affichée dans l’interface
Elle est convertie au format local pour faciliter la lecture. Lors d’une capture d’écran, notez aussi le fuseau de l’appareil afin d’éviter les erreurs entre équipes.
Point de départ de la validité
Le compte à rebours d’un code peut commencer à sa génération, à son envoi ou à son émission par le serveur. Fiez-vous au contrat du produit.
Temps restant
Le compte à rebours est une valeur dérivée. Après un passage en arrière-plan, une veille ou une modification de l’horloge de l’appareil, recalculez-le à partir de l’heure d’expiration absolue.
Diagnostic des délais
Décomposez le délai total en trois étapes
Ce n’est qu’en sachant où le temps est passé que vous pouvez décider d’examiner les journaux de l’application, la file d’envoi ou la politique de réception.
Si l’intervalle entre le déclenchement et la mise en file est important, vérifiez la requête de l’application, le rendu du modèle et le service de tâches.
Si l’intervalle entre la mise en file et l’envoi est important, vérifiez la limitation de débit, la concurrence, les nouvelles tentatives et l’état du fournisseur.
Si l’intervalle entre l’envoi et la réception est important, vérifiez le DNS, la réputation, les refus temporaires et les politiques du serveur distant.
Si le serveur a déjà reçu l’e-mail mais que la liste l’affiche tardivement, vérifiez la fréquence d’interrogation, le cache et le réseau du client.
Comment tester l’expiration d’un code
Confirmez d’abord quel événement serveur lance la période de validité, puis testez l’utilisation pendant la période, autour de la limite et après une réutilisation. Ne remplacez pas l’expiration côté serveur par une modification manuelle de l’horloge de l’appareil.
- Une utilisation immédiate après la génération doit réussir
- Le comportement autour de la limite d’expiration doit être explicite
- Après l’émission d’un nouveau code, le comportement de l’ancien doit respecter le contrat
Comment consigner les échanges entre fuseaux horaires
Dans un ticket, conservez l’heure ISO d’origine, le décalage du fuseau et l’heure locale lisible. Si une capture indique « dix heures du matin », précisez le fuseau de l’appareil.
- Reliez les journaux des différents systèmes avec l’ID d’événement
- Utilisez UTC comme référence de comparaison pour l’équipe
- Utilisez l’heure locale pour reconstituer l’expérience utilisateur
Vérification rapide
Face à un « retard », répondez à ces quatre questions
Ces quatre questions écartent la plupart des malentendus liés aux fuseaux et localisent le véritable délai dans un maillon système vérifiable.
D’où vient l’heure ?
Provient-elle des journaux de l’application, des en-têtes de l’e-mail, du serveur de réception ou de la liste du navigateur ? Chaque source correspond à un événement différent.
Quel est le fuseau horaire ?
L’heure comporte-t-elle un Z, un décalage explicite ou un fuseau régional ? Sans fuseau, elle ne constitue qu’une preuve incomplète.
Comparez-vous bien le même e-mail ?
L’identifiant unique dans l’objet, l’adresse destinataire et l’ID de tâche doivent correspondre. Vous éviterez ainsi de comparer par erreur des e-mails renvoyés.