Retour au blog Qualité et confiance

Disjoncteur pour OTP par SMS : seuils, états et récupération sûre

Guide opérationnel pour limiter de manière réversible l’envoi d’OTP par SMS lorsque l’acceptation, les états de livraison ou la latence se dégradent, sans transformer la protection en blocage pour les utilisateurs légitimes.

Tableau de bord opérationnel affichant les états d’un disjoncteur pour OTP par SMS

Quel problème un disjoncteur résout dans les flux OTP par SMS

Un disjoncteur pour OTP par SMS est un contrôle opérationnel qui réduit ou modifie temporairement les envois lorsque des signaux de dégradation apparaissent dans un segment donné. Son objectif est de protéger la continuité du flux d’authentification, de limiter l’impact d’une route ou d’une destination affectée et d’éviter qu’un incident n’amplifie les nouvelles tentatives, les doublons et les expirations de codes.

Il ne remplace pas les contrôles de sécurité de l’OTP. La limite des tentatives de validation du code, la durée de validité du secret, l’usage unique et les défenses contre les abus sont des contrôles distincts. Le disjoncteur intervient sur la décision d’envoyer ou de traiter des demandes de messagerie ; il ne doit pas réinitialiser les limites d’authentification simplement parce qu’un nouveau code est émis.

Dans un flux hors bande par SMS, le secret de courte durée est généré pour une opération d’authentification et transmis via un canal secondaire. Un problème de livraison peut donc empêcher la finalisation d’une authentification légitime, mais la solution ne consiste pas nécessairement à arrêter tout le trafic. Le segment affecté doit être isolé et une réponse proportionnée doit être appliquée.

  • Objectif : limiter le rayon d’impact de la dégradation.
  • Périmètre : décisions d’envoi, de mise en file, de débit, de routage ou d’authentificateur alternatif autorisé.
  • Ce n’est pas : une détection de fraude, un substitut à la limitation du débit de vérification ni une garantie de livraison.
  • Principe opérationnel : des décisions réversibles, segmentées et auditables.
Quel problème un disjoncteur résout dans les flux OTP par SMS

Pourquoi une hausse des DLR négatifs ne suffit pas à bloquer automatiquement les envois

Un identifiant renvoyé lors de la soumission d’un message à une API, à un fournisseur ou à un SMSC confirme l’acceptation de cette soumission selon le protocole ou l’intégration ; il ne confirme pas que le téléphone a reçu l’OTP. La livraison est une phase ultérieure qui doit être observée séparément au moyen des états disponibles.

Il ne faut pas non plus considérer tout DLR négatif comme une raison suffisante pour ouvrir un circuit global. En SMPP, il existe des états intermédiaires, tels que ENROUTE, et des états finaux comme DELIVERED, EXPIRED, DELETED ou UNDELIVERABLE. Un message dans un état intermédiaire peut encore être en cours de traitement ou de nouvelle tentative avant d’atteindre un état final.

L’absence de DLR ne signifie pas non plus automatiquement une non-livraison. Le retour des accusés dépend de la configuration de registered_delivery ainsi que de l’implémentation du centre de messagerie ou du fournisseur. Une politique robuste définit quelle absence d’état final est pertinente, pendant combien de temps et pour quelles cohortes, au lieu de supposer que tout silence est un échec.

  • Distinguer l’acceptation de soumission, l’état de livraison et la validation réussie de l’OTP.
  • Classer ENROUTE comme un état intermédiaire, et non comme un résultat final.
  • Évaluer les DLR négatifs dans leur contexte de volume, de délai, de destination et de route.
  • Traiter l’absence de DLR comme une incertitude d’observabilité, et non comme une preuve de non-réception.
  • Ne pas supposer qu’un DLR DELIVERED prouve de manière indépendante la réception ou la lecture par l’utilisateur.
Pourquoi une hausse des DLR négatifs ne suffit pas à bloquer automatiquement les envois

Les signaux à distinguer

Le circuit ne doit pas être alimenté par une seule métrique agrégée. Chaque signal décrit une phase différente et peut nécessiter une action différente. Mélanger, par exemple, les échecs d’API et les DLR tardifs peut masquer si l’incident se situe dans l’intégration, avant l’acceptation, dans l’observabilité des états ou sur une route de livraison.

Définissez des événements normalisés et une taxonomie stable avant de fixer des seuils. La valeur du mécanisme dépend du fait que la même condition produise la même classification, même lorsque l’équipe d’astreinte ou l’implémentation d’une route change.

  • Erreurs d’intégration ou de transport : échecs d’authentification, de connectivité, délais d’attente et erreurs de protocole entre l’application et le point d’envoi.
  • Rejets préalables : demandes non acceptées par l’interface d’envoi. Ils doivent être distingués d’un message accepté qui n’atteint ensuite aucun état final favorable.
  • États finaux négatifs : résultats finaux communiqués ultérieurement pour des messages acceptés.
  • États intermédiaires : messages encore en cours de traitement ; ils ne doivent pas être ajoutés directement aux échecs finaux.
  • Latence : délai entre la soumission acceptée et l’état final disponible, analysé par cohorte.
  • Absence d’état final : messages sans état final dans le délai défini par la politique.
  • Comportement de renvoi : demandes répétées, doublons potentiels, nouveaux OTP émis et validations ultérieures.

Modèle à trois états : fermé, ouvert et test de récupération contrôlé

Le modèle le plus simple et le plus traçable repose sur trois états. À l’état fermé, le segment fonctionne selon la politique normale et les signaux sont observés. À l’état ouvert, l’action de protection définie pour ce segment est appliquée. En test de récupération contrôlé, une portion limitée et explicitement régie du trafic est libérée afin de vérifier si la dégradation a disparu.

Il n’existe pas de pourcentage, de durée ni de taux d’erreur universel convenant à toutes les destinations. Ces valeurs doivent être des paramètres de politique approuvés par l’équipe responsable, ajustés au volume, à la validité de l’OTP, aux alternatives disponibles et au risque d’affecter des utilisateurs légitimes.

La transition doit être déterministe. Précisez quels signaux ouvrent le circuit, combien de temps il reste initialement ouvert, à quel moment il peut entrer en test et quelle condition le fait revenir à l’état ouvert. Évitez les changements manuels sans trace, car ils empêchent de reconstituer la raison d’une décision.

  • Fermé : envoi normal et collecte des signaux par segment.
  • Ouvert : pause, limitation, mise en file conditionnelle ou alternative autorisée selon la politique.
  • Test contrôlé : libération limitée et observée avant le rétablissement du fonctionnement normal.
  • Réouverture : retour immédiat à l’état ouvert si les signaux définis réapparaissent.
  • Fermeture : rétablissement uniquement après le respect de critères de stabilité et un volume suffisant.

Comment définir des seuils avec un volume minimum, une fenêtre temporelle et une segmentation

Calculez les seuils sur des cohortes opérationnelles cohérentes. Au minimum, segmentez par pays ou par plan de numérotation. Lorsque la télémétrie est fiable, ajoutez l’opérateur de destination et la route. Une moyenne globale peut masquer une dégradation localisée ou, à l’inverse, ouvrir un blocage étendu à cause du comportement d’une petite partie du trafic.

Chaque seuil doit déclarer trois éléments : une fenêtre temporelle, un volume minimal d’observations et une condition de dégradation. Sans volume minimal, un faible échantillon peut générer un taux extrême et instable. Sans fenêtre, un événement ancien peut influencer la décision trop longtemps ou une brève pointe peut provoquer une réaction excessive.

Gardez distincts les seuils d’intégration, de rejet, de résultat final, de latence et d’absence d’état final. Il est également utile de prévoir une politique pour les segments nouveaux ou à faible volume : plutôt que d’en déduire un taux concluant, une revue opérationnelle peut être exigée ou une action plus prudente et réversible peut être appliquée.

  • Segment recommandé : destination de numérotation ; compléter par opérateur et route lorsque des données fiables sont disponibles.
  • Fenêtre : exprimer la période exacte de calcul et sa méthode d’actualisation.
  • Volume minimal : ne pas évaluer les taux d’ouverture avant d’atteindre le minimum approuvé.
  • Condition : définir quelle combinaison de signal, de proportion et de persistance déclenche la transition.
  • Exclusions : documenter les maintenances, les changements planifiés ou les événements d’instrumentation qui invalident l’interprétation.
  • Version : attribuer une version à chaque ensemble de seuils et conserver son historique.

Quelles actions appliquer à l’ouverture du circuit

Ouvrir un circuit ne signifie pas nécessairement abandonner chaque demande. L’action doit respecter la durée de validité de l’OTP et l’impact sur l’utilisateur. Une file d’attente n’est utile que si le code reste valide et si le délai ne pousse pas la personne à demander à répétition de nouveaux messages. S’il n’a plus d’utilité, il est préférable de ne pas réactiver l’ancienne demande.

Les alternatives d’authentification doivent être activées et approuvées avant un incident. N’improvisez pas un canal alternatif dont l’usage n’est pas autorisé par la politique d’authentification. En particulier, l’e-mail ne doit pas être utilisé pour l’authentification hors bande selon NIST, même s’il peut servir à d’autres usages, tels que la confirmation d’adresse ou la récupération, selon sa propre politique.

La décision peut différer selon la gravité. Un échec complet de l’intégration peut exiger une pause immédiate dans le périmètre concerné. Une hausse de la latence ou de l’incertitude des DLR peut justifier une limitation du débit ou un test de routes autorisées, à condition que l’organisation dispose de ces options et puisse en observer les résultats.

  • Suspendre les nouveaux envois vers le segment affecté.
  • Limiter le débit afin de réduire l’amplification d’une dégradation.
  • Mettre en file uniquement les demandes qui peuvent être finalisées pendant la durée utile de validité de l’OTP.
  • Rediriger conformément à une politique préalablement approuvée vers une alternative ou une route disponible.
  • Présenter à l’utilisateur une méthode d’authentification alternative déjà autorisée et configurée.
  • Ne pas réutiliser des OTP consommés ni réactiver sans discernement des demandes anciennes.

Comment éviter de bloquer les utilisateurs légitimes

Un disjoncteur mal segmenté peut transformer une dégradation localisée en refus d’accès pour des utilisateurs légitimes. Pour réduire ce risque, limitez le périmètre initial, privilégiez les actions réversibles et évaluez les effets négatifs du contrôle en même temps que son efficacité opérationnelle.

Ne laissez pas le renvoi devenir une issue sans limites. Lorsqu’un utilisateur ne reçoit pas un OTP, les nouvelles tentatives peuvent augmenter le volume, provoquer des doublons et générer des codes dont les périodes de validité se chevauchent. Le flux doit prévoir des règles claires pour associer les demandes, conserver les limites d’authentification et déterminer quel secret reste valide selon la politique.

Les SMS/PSTN présentent leurs propres limites et risques, notamment le phishing, le changement de SIM, le portage et le renvoi de service. Le disjoncteur peut améliorer la continuité de l’envoi, mais il n’élimine pas ces risques. Les décisions d’authentification doivent conserver leurs contrôles de risque et leurs authentificateurs alternatifs indépendamment de l’état de livraison.

  • Appliquer le circuit au segment le plus étroit expliqué par les signaux.
  • Mesurer les abandons, les nouvelles tentatives et les échecs de vérification après chaque activation.
  • Ne pas réinitialiser les limites d’échecs d’authentification lors de l’émission d’un nouveau secret.
  • Proposer des voies de récupération et des authentificateurs alternatifs aux personnes qui ne peuvent pas utiliser le PSTN.
  • Distinguer un problème de messagerie d’un signal de fraude ou d’un échec de vérification.

Conception de la récupération : tests progressifs, fermeture et réversion

La récupération doit être aussi explicite que l’ouverture. Après la période initiale à l’état ouvert, le système peut passer en test contrôlé si les exigences de la politique sont remplies. Ce test doit avoir un périmètre limité, une observation renforcée et des critères d’interruption immédiats si les signaux de dégradation réapparaissent.

Ne fermez pas le circuit simplement parce qu’un délai s’est écoulé. Exigez des éléments probants dans la même cohorte affectée : un volume suffisant, un comportement d’acceptation attendu, des résultats de livraison disponibles dans le délai applicable et l’absence de la condition ayant déclenché l’ouverture. Si l’observabilité des DLR est incomplète, ne déclarez pas une récupération de la livraison sur la seule absence d’erreurs.

Une réversion sûre évite qu’un incident oscillant transforme le système en une succession d’ouvertures et de fermetures difficiles à expliquer. Maintenez une durée initiale d’ouverture, des règles de réentrée en test et une condition claire de réouverture. Enregistrez chaque transition.

  • Entrer en test uniquement selon des critères préalables et documentés.
  • Libérer un trafic limité dans la cohorte exacte en cours de vérification.
  • Observer les mêmes signaux que ceux ayant motivé l’ouverture, et non une seule métrique favorable.
  • Fermer après la stabilité et le volume suffisant définis par la politique.
  • Revenir à l’état ouvert si la condition de dégradation réapparaît.
  • Revoir la configuration si le circuit oscille de façon répétée.
FAQ

Questions fréquentes

Un submit_sm_resp réussi confirme-t-il que l’utilisateur a reçu l’OTP ?

Non. Il confirme que le SMSC a renvoyé un identifiant pour le message soumis selon SMPP. La livraison est signalée ultérieurement, lorsqu’elle est disponible, au moyen d’événements d’état. Même un DLR doit être interprété comme un élément relatif à l’état de la messagerie, et non comme une preuve indépendante de lecture par l’utilisateur.

L’absence de DLR signifie-t-elle que le SMS n’a pas été livré ?

Pas nécessairement. Le retour des accusés dépend de registered_delivery et de l’implémentation du centre de messagerie ou du fournisseur. L’absence doit être classée comme une absence d’état final dans le délai défini par la politique, et non comme une preuve automatique de non-réception.

Faut-il ouvrir un disjoncteur global lorsque les DLR négatifs augmentent ?

Pas comme règle automatique. Évaluez le volume minimal, la fenêtre temporelle et la cohorte affectée. Segmentez au moins par destination de numérotation et, si l’information est fiable, par opérateur et par route. Une moyenne globale peut masquer le problème ou l’étendre indûment.

Peut-on utiliser l’e-mail comme alternative immédiate pour l’authentification hors bande ?

Il ne doit pas être utilisé pour l’authentification hors bande selon NIST. Les alternatives doivent être approuvées, mises en œuvre et évaluées dans le cadre de la politique d’authentification avant qu’une dégradation ne survienne.

Que se passe-t-il pour les OTP placés en file lorsque le circuit s’ouvre ?

Ils ne doivent être conservés que s’ils peuvent encore être utiles durant leur période de validité et si la politique autorise leur traitement. Il n’est pas recommandé de réactiver sans discernement des demandes anciennes ni de réutiliser des secrets consommés. Les OTP doivent être à usage unique.

Que faut-il enregistrer à chaque changement d’état ?

Au minimum : l’identifiant de corrélation, le segment affecté, l’état précédent et le nouvel état, les signaux et sources ayant motivé la décision, la version des seuils, l’action appliquée, les responsables et le résultat des tests de récupération.

Sources consultées

  1. NIST SP 800-63B — autenticación fuera de banda y uso de PSTNNational Institute of Standards and Technology (NIST)
  2. SMPP Protocol Specification v3.4 — Appendix B, Delivery Receipt FormatSMPP Developers Forum
  3. SMPP Delivery Receipts — estados finales e intermediosSMPP Developers Forum
  4. TS 23.040 — Technical realization of the Short Message Service3GPP / ETSI
  5. ITU-T Recommendation E.164 — plan internacional de numeración públicaInternational Telecommunication Union (ITU)
  6. OWASP Authentication Cheat Sheet — registro y supervisión de autenticaciónOpen Worldwide Application Security Project (OWASP)