Budget de latence OTP par SMS : définir l’expiration et les objectifs sans se fier à la moyenne
Apprenez à décomposer, mesurer et piloter la latence d’un OTP par SMS grâce aux percentiles, à la segmentation et aux signaux fonctionnels, sans confondre acceptation, DLR et utilisation réelle du code.
Le problème résolu par un budget de latence dans un flux OTP par SMS
Un budget de latence OTP SMS transforme une attente imprécise — « le code doit arriver rapidement » — en un modèle opérationnel mesurable. Son rôle est de séparer les étapes du parcours, d’attribuer les responsabilités, de choisir des signaux observables et de décider combien de temps un code reste valide sans s’appuyer sur une moyenne globale de livraison.
Dans un flux d’authentification hors bande, le vérificateur génère un secret temporaire, l’envoie via un canal secondaire tel que le SMS, puis l’utilisateur le renvoie par le canal principal. Le parcours pertinent ne s’achève donc pas lorsqu’une plateforme accepte la demande d’envoi, ni nécessairement lorsqu’un rapport de livraison est reçu : il se termine lorsque le vérificateur accepte la présentation valide de l’OTP.
Le budget permet de prendre des décisions produit et opérationnelles : définir une expiration raisonnable, établir le moment où proposer le renvoi, détecter une dégradation par destination ou par route, et éviter d’attribuer au réseau mobile un délai provenant de l’application ou d’une file d’attente interne.
- Définissez le résultat fonctionnel comme la validation réussie de l’OTP, et non seulement comme l’envoi du message.
- Modélisez les étapes séparément avant de fixer un objectif de temps.
- Mesurez par segments opérationnels ; une valeur globale peut masquer des dégradations concentrées.
- Conservez la sécurité comme contrainte de conception : le code doit être temporaire et ne pouvoir être accepté qu’une seule fois.
Pourquoi la latence moyenne ne permet pas de définir l’expiration d’un code
La moyenne répond mal à une question produit essentielle : de combien de temps la grande majorité des utilisateurs légitimes a-t-elle besoin pour terminer le flux ? Un ensemble de livraisons rapides peut faire baisser la moyenne alors qu’une part significative des expériences reste lente. Si l’expiration est définie à partir de cette moyenne, les cas situés dans la longue traîne expirent régulièrement, même si l’indicateur agrégé semble satisfaisant.
L’expiration ne couvre pas uniquement le transport du SMS. Elle doit couvrir le temps écoulé entre la création du secret et sa saisie puis sa validation, y compris le traitement interne, la transmission, un éventuel délai réseau, la disponibilité du terminal et le temps nécessaire à l’utilisateur pour lire et saisir le code.
Le NIST indique que, pour les OTP basés sur le temps, la durée de vie doit tenir compte de la dérive d’horloge attendue, d’une tolérance pour le délai réseau et du temps de saisie par l’utilisateur. Ce principe évite de concevoir une expiration à partir d’une seule mesure de latence d’un fournisseur ou d’une route.
- N’utilisez pas la moyenne comme critère principal d’expiration ni comme unique SLO.
- Observez les percentiles élevés du temps jusqu’à validation, ainsi que les taux de réussite et d’expiration.
- Analysez des fenêtres temporelles comparables, et pas seulement des agrégats historiques.
- Distinguez un retard de transport d’une validation tardive due à l’interaction de l’utilisateur.
Définitions opérationnelles et horodatages minimaux
Avant toute mesure, définissez précisément chaque événement et enregistrez son horodatage. Des définitions ambiguës produisent des comparaisons non valides entre équipes, fournisseurs ou destinations. Utilisez un identifiant de corrélation interne pour la tentative d’authentification et un identifiant de message pour l’envoi, tout en conservant des données de corrélation non sensibles.
Une séquence pratique commence par la création de l’OTP et son association à la transaction d’authentification. Elle enregistre ensuite la demande adressée au canal d’envoi, l’acceptation de cette demande par API ou SMPP, les événements disponibles de mise en file d’attente et d’envoi, tout DLR reçu et, enfin, la validation réussie ou échouée du code.
L’acceptation par API ou SMPP atteste uniquement que le fournisseur a correctement reçu la commande ou la demande. Elle ne prouve pas que le SMS est arrivé sur l’appareil. De même, un DLR est un signal asynchrone dont la signification dépend du rapport reçu et de la chaîne de livraison ; il doit être conservé comme preuve opérationnelle, sans être traité comme une preuve de lecture ni comme une horloge définitive de livraison.
- t0 : création de l’OTP et ouverture de sa période de validité.
- t1 : demande d’envoi émise par l’application.
- t2 : acceptation par API ou SMPP et attribution de l’identifiant de message, s’il existe.
- t3 : événements d’envoi ou de changement de statut disponibles sur la plateforme.
- t4 : réception du DLR et, lorsqu’ils sont fournis, horodatages et tentatives figurant dans le rapport lui-même.
- t5 : présentation et validation réussie de l’OTP, ou enregistrement de l’expiration, de l’échec ou de l’abandon.
Les éléments contrôlés par chaque acteur
L’émetteur contrôle la conception de l’expérience, la génération du code, la création de la demande, le comportement de l’application, ses propres files d’attente, les règles d’expiration, les limites de tentatives et l’instrumentation. Il peut également choisir la connectivité disponible, définir des politiques par destination et agir sur les routes conformément à ses accords et contrôles opérationnels.
Le fournisseur de messagerie et les intermédiaires contrôlent certaines parties de l’acceptation, du traitement et de la livraison vers les réseaux connectés, selon l’architecture et les accords applicables. Le réseau mobile contrôle des éléments de routage et de livraison signalée au sein de son domaine. Le terminal, la couverture disponible, l’état de l’appareil et le comportement de l’utilisateur échappent au contrôle direct de l’émetteur.
Cette séparation doit se refléter dans le diagnostic. Si le temps entre création et acceptation augmente, examinez d’abord l’application ou la connectivité sortante. Si l’acceptation reste stable mais que la distribution des DLR ou des validations évolue pour une destination, examinez le segment concerné sans conclure qu’un événement unique prouve la cause.
- Application : génération, stockage sécurisé, expiration, interface utilisateur, demande et validation.
- Connectivité d’envoi : acceptation, réponse technique et identifiants de message.
- Route et réseau mobile : traitement de la livraison et signaux d’état éventuellement signalés.
- Terminal et utilisateur : disponibilité pratique du code, lecture et saisie.
- Vérificateur : décision finale d’accepter ou de rejeter l’OTP présenté.
Comment construire un budget de latence par étapes
Construisez le budget à partir du résultat qui compte : une validation valide avant expiration. Commencez par recueillir les événements de tentatives réelles d’authentification, avec une corrélation entre la tentative, le message et le résultat de vérification. Excluez de la définition les événements qui ne peuvent pas être reliés de manière fiable, mais quantifiez ce manque de corrélation comme une limite d’observabilité.
Calculez des distributions pour chaque intervalle : création à demande, demande à acceptation, acceptation à tout signal ultérieur disponible, et création à validation réussie. Distinguez les tentatives validées, expirées, abandonnées, échouées et celles dans lesquelles le code était incorrect. Les mélanger dans une seule série masque des problèmes de sécurité, d’expérience utilisateur et de livraison.
Le budget final n’est pas la promesse que tous les messages seront finalisés dans un délai fixe. C’est une politique : une fenêtre de validité accompagnée de limites de renvoi, de contrôles de tentatives, d’alternatives d’authentification lorsque cela convient et de seuils opérationnels par segment.
- 1. Définissez l’événement de début : généralement la création de l’OTP.
- 2. Définissez l’événement fonctionnel de fin : validation réussie par le vérificateur.
- 3. Enregistrez les intervalles intermédiaires avec des horodatages distincts.
- 4. Classez le résultat de toutes les tentatives.
- 5. Calculez les percentiles par segment et par fenêtre temporelle.
- 6. Définissez l’expiration en tenant compte du transport, de l’interaction humaine et des exigences de sécurité.
- 7. Révisez la politique après des changements de route, de produit, de connectivité ou de comportement du trafic.
Percentiles, fenêtres temporelles et segmentation par destination
Utilisez les percentiles pour décrire la distribution, et non seulement un point central. Les percentiles du temps jusqu’à validation permettent d’observer l’expérience de la part la plus lente des utilisateurs qui terminent le flux. Ils doivent être interprétés avec la proportion de tentatives qui expirent, le taux de validation et le volume, car un percentile calculé sur peu d’observations peut être instable.
Segmentez au minimum par destination. Lorsque les données et le volume le permettent, ajoutez des dimensions utiles à l’exploitation : route, expéditeur, type de numéro, type de trafic, version de l’application ou politique de risque. Ne mélangez pas des segments aux comportements différents en espérant ensuite qu’un seuil global unique explique la cause d’un écart.
Comparez chaque segment à sa propre ligne de base dans des fenêtres temporelles cohérentes. Une fenêtre trop courte réagit au bruit ; une fenêtre excessivement longue peut retarder la détection. Définissez également un volume minimal d’observations avant de prendre des décisions automatisées ou de déclencher une alerte.
- Mesurez le temps entre création et validation comme métrique fonctionnelle principale.
- Mesurez le temps entre création et acceptation afin d’isoler les délais internes ou de connectivité.
- Conservez les DLR et leurs horodatages comme télémétrie complémentaire, et non comme substitut à la validation.
- Analysez le pourcentage d’expirations, de renvois, de tentatives échouées et de validations réussies avec les temps.
- Exigez un volume suffisant avant de comparer des percentiles entre segments.
Expiration, renvoi, limites de demande et prévention des doublons
La fenêtre d’expiration doit être suffisamment large pour couvrir l’expérience légitime prévue, mais elle ne doit pas devenir un substitut aux contrôles de sécurité. Pour l’authentification hors bande couverte par le NIST, la transaction doit être achevée dans les 10 minutes et un secret donné ne peut être accepté qu’une seule fois pendant sa période de validité. Appliquez toujours les exigences réglementaires, contractuelles et de risque correspondant à votre cas d’usage.
Le renvoi ne doit pas créer une tempête de messages ni étendre indéfiniment la surface d’attaque. Avant d’émettre un autre SMS, vérifiez si un OTP valide est associé à la même transaction et décidez explicitement s’il est réutilisé, invalidé et remplacé, ou si la demande est limitée. La politique doit être cohérente afin d’éviter plusieurs codes actifs ambigus sans règle de validation claire.
Pour les secrets courts, limitez efficacement les tentatives échouées consécutives. L’émission d’un nouveau secret ne doit pas réinitialiser le compteur d’échecs. Vous pouvez utiliser des délais progressifs et des signaux de risque pour renforcer le flux lorsque des schémas anormaux apparaissent, tout en conservant des alternatives d’authentification lorsque le risque, la couverture ou l’accessibilité l’exigent.
- Conservez un état faisant autorité unique par transaction d’authentification.
- Faites en sorte que chaque OTP ne puisse être utilisé qu’une seule fois.
- Définissez une politique explicite pour l’OTP précédent après un renvoi.
- Limitez les demandes de renvoi par compte, session, destination et signaux de risque pertinents.
- Ne réinitialisez pas les limites de tentatives échouées lors de l’émission d’un nouveau code.
- Proposez des alternatives d’authentification lorsque le SMS/PSTN n’est pas approprié ou n’est pas disponible.
Ce qu’un DLR peut indiquer et ce qu’il ne peut pas démontrer
Un DLR peut apporter des informations opérationnelles utiles : état signalé, tentatives de livraison et, selon l’interface, horodatages de la tentative et de la réception du rapport. Il est précieux pour examiner les tendances et pour distinguer une réponse technique initiale d’un état de livraison communiqué ultérieurement.
Toutefois, le DLR ne prouve pas à lui seul que l’utilisateur a lu, compris ou saisi le code. Il ne doit pas non plus servir d’horloge pour décider immédiatement qu’il existe un retard de livraison. Les accusés de réception ou événements générés par les opérateurs peuvent arriver tardivement ; la documentation AWS avertit qu’ils peuvent être reçus jusqu’à 72 heures plus tard et qu’ils ne doivent pas être utilisés pour déterminer un retard de livraison sortante.
La validation réussie de l’OTP est un signal fonctionnel plus robuste : elle démontre que le code est devenu disponible pour l’utilisateur et qu’il a été présenté au vérificateur. Cela ne rend toutefois pas le DLR inutile ; les deux signaux répondent à des questions différentes et doivent être conservés séparément.
- Acceptation de l’envoi : la commande ou la demande a été correctement reçue.
- DLR : résultat de livraison signalé de manière asynchrone, avec une incertitude sur le délai et le périmètre.
- Validation réussie : preuve fonctionnelle que le code a été correctement présenté au vérificateur.
- Absence de DLR : elle ne doit pas être automatiquement interprétée comme une absence de livraison.
- DLR Delivered : il ne prouve ni la lecture ni la saisie correcte du code.
Questions fréquentes
Quelle métrique doit guider l’expiration d’un OTP par SMS ?
La référence la plus utile est la distribution du temps entre la création de l’OTP et sa validation réussie, segmentée par destination et par d’autres dimensions opérationnelles pertinentes. Elle doit être complétée par les taux d’expiration, de renvoi et d’échec, et non par une moyenne de livraison isolée.
L’acceptation par API ou SMPP signifie-t-elle que le SMS est arrivé sur le téléphone ?
Non. Elle indique que la commande ou la demande a été correctement reçue par le système qui l’accepte. Elle ne démontre pas la réception sur l’appareil de destination.
Un DLR Delivered prouve-t-il que l’utilisateur a reçu et lu l’OTP ?
Non. Un DLR représente un résultat de livraison signalé et peut être utile comme signal opérationnel, mais il ne prouve ni la lecture, ni la compréhension, ni la saisie du code. La validation réussie est le signal fonctionnel le plus robuste.
Combien de temps un OTP envoyé par SMS doit-il rester valide ?
Il n’existe pas de durée universelle pouvant être déduite d’une moyenne de livraison. Définissez-la à partir de la distribution des temps jusqu’à validation, du temps d’interaction attendu, du risque et des exigences applicables. Pour l’authentification hors bande couverte par le NIST, la transaction doit être achevée dans les 10 minutes.
Faut-il générer un nouveau code chaque fois que l’utilisateur demande un renvoi ?
Une politique explicite doit exister. Si un nouveau code est généré, définissez ce qui arrive au précédent pour éviter toute ambiguïté et ne réinitialisez pas les contrôles de tentatives échouées. Il est également recommandé de limiter les demandes de renvoi et d’appliquer des délais ou des mesures adaptatives lorsque cela est nécessaire.
Comment détecter la dégradation d’une route OTP ?
Comparez les percentiles du temps jusqu’à validation, les taux d’expiration, les renvois et les signaux de livraison à une ligne de base propre, en segmentant par destination, route, expéditeur ou autres dimensions disponibles. Exigez un volume suffisant et un écart durable avant d’attribuer un pic isolé à un problème de route.
Sources consultées
- NIST SP 800-63B: autenticación fuera de banda y secretos temporalesNational Institute of Standards and Technology (NIST)
- AWS End User Messaging SMS User Guide: eventos, DLR y feedback de mensajesAmazon Web Services (AWS)
- Azure Communication Services SMS Delivery Reports APIMicrosoft
- Azure Communication Services: eventos SMSMicrosoft
- OWASP Authentication Cheat SheetOWASP Foundation