Validité des messages SMS A2P : définir l’expiration, les tentatives et les états finaux sans nuire à l’utilisateur

La validité d’un SMS n’est pas l’expiration de son contenu

Dans le SMS, la période de validité décrit combien de temps un message doit être conservé afin de tenter sa livraison avant son expiration. Il s’agit d’un attribut de transport et de rétention sur le réseau ; elle ne détermine pas à elle seule si le contenu reste approprié pour le destinataire.

Cette distinction est essentielle pour le trafic A2P. Un SMS peut rester techniquement délivrable alors que le code OTP n’est plus acceptable, que l’alerte a déjà été résolue ou qu’une promotion a perdu sa pertinence. Conserver le message en file d’attente dans ces cas peut créer de la confusion, des demandes d’assistance et de mauvaises décisions de sécurité.

La politique opérationnelle ne doit pas se limiter à demander si le fournisseur ou le réseau peut encore délivrer le SMS. Elle doit répondre à une question préalable : « L’action demandée reste-t-elle correcte, sûre et utile si le destinataire reçoit ce message maintenant ? »

• Validité technique : durée maximale de conservation et de tentatives de livraison sur la plateforme, chez le fournisseur ou sur le réseau.
• Expiration du contenu : instant à partir duquel un code, un lien ou une donnée inclus cesse d’être valide.
• Fenêtre d’utilité : délai pendant lequel recevoir la communication permet encore au destinataire d’effectuer une action pertinente.

Utilisez une limite absolue d’utilité comme décision de contrôle

La plateforme émettrice doit calculer une échéance absolue d’utilité lors de la création de l’opération. Cet instant doit accompagner le message durant sa mise en file d’attente, la régulation par TPS, la sélection de connectivité, l’envoi et les tentatives.

Avant chaque transition importante, vérifiez qu’il reste suffisamment de temps pour que le message conserve son sens. Si l’attente interne, la limite d’émission ou une nouvelle tentative ont déjà consommé cette fenêtre, la bonne décision est généralement de ne pas envoyer. Il ne faut pas déléguer cette décision uniquement à la période de validité configurable d’un tiers, car cette valeur peut ne s’appliquer qu’au temps de présence dans sa propre plateforme.

Le contrôle doit être exécuté avant d’admettre le travail dans une file de sortie, avant de l’émettre à un fournisseur et avant de planifier chaque tentative. Cela évite qu’un message obsolète soit envoyé simplement parce qu’il reste encore une capacité technique de transport.

• Définissez une heure d’expiration d’utilité pour chaque opération.
• Réservez un budget de temps pour la file interne, la régulation par TPS, l’acceptation par le fournisseur et les tentatives.
• Supprimez avant l’envoi si le budget restant ne permet plus une livraison utile.
• Conservez l’expiration de la plateforme comme protection supplémentaire, et non comme seul contrôle métier.

Définissez des politiques distinctes pour les OTP, les messages transactionnels et les campagnes avec consentement

Il n’existe pas de délai unique adapté à toutes les catégories de trafic. La politique doit découler de l’action attendue, des conséquences d’un message tardif et de la possibilité de le remplacer par des informations actualisées. Le délai doit être documenté comme une règle produit et opérationnelle, et non comme une hypothèse sur la latence d’une route.

Pour les OTP, la référence principale est la durée de validité du secret et le contexte d’authentification. Pour les communications transactionnelles, il importe de savoir si l’événement reste ouvert ou s’il existe un état plus récent. Pour les campagnes avec consentement, l’opportunité commerciale et l’évitement d’une répétition tardive que le destinataire n’attend pas sont particulièrement importants.

Les délais précis doivent être approuvés par les équipes responsables du flux, de la sécurité, de la confidentialité ou de la protection des données, de la conformité, ainsi que par les exigences réglementaires ou contractuelles locales applicables. La plateforme doit mettre en œuvre ces délais de manière vérifiable et permettre d’identifier quelle règle a été appliquée à chaque opération.

• OTP et récupération : fenêtre courte, alignée sur l’acceptation du secret ; supprimer si elle expire avant l’envoi.
• Alertes transactionnelles : envoyer tant que l’événement reste pertinent ; remplacer par une mise à jour si l’état a changé.
• Confirmations : ne renvoyez pas un ancien message si une confirmation ultérieure représente mieux l’état actuel.
• Campagnes avec consentement : ne relancez pas automatiquement lorsque la date, le créneau ou l’opportunité de l’offre est déjà passé.

OTP : coordonnez le transport et le secret, sans les confondre

Dans un flux d’authentification conçu conformément aux exigences applicables, le vérificateur doit n’accepter le secret qu’une seule fois pendant sa période de validité. Il doit le rejeter lorsqu’il expire, même si le SMS est délivré après. Le fait que le message atteigne l’appareil ne prolonge pas la validité du code et ne réactive pas l’opération d’authentification.

Dans le cadre d’authentification hors bande décrit par NIST SP 800-63B, l’authentification doit être finalisée dans les dix minutes et un secret donné ne doit être accepté qu’une seule fois durant sa période de validité. Cette référence ne supprime pas la nécessité d’une politique propre à la file d’attente : l’émetteur doit empêcher qu’un code qui ne peut plus servir continue sa progression vers la livraison.

Dans le cadre applicable de NIST, les tentatives échouées doivent également être limitées lorsque le secret comporte moins de 64 bits. L’émission d’un nouveau secret ne doit pas réinitialiser ce compteur. Cette règle relève du vérificateur et ne peut pas être déduite de l’état de transport du SMS.

NIST SP 800-63B prévoit, dans son cadre d’assurance et pour l’authentification hors bande concernée, des alternatives d’authentificateur pour les abonnés qui ne peuvent pas utiliser le RTPC. Les équipes de risque doivent également prendre en compte les signaux pertinents pour le cas d’usage, tels que les changements de SIM, le portage ou le changement d’appareil.

Références : NIST SP 800-63B, [Digital Identity Guidelines](https://pages.nist.gov/800-63-4/sp800-63b.html) ; 3GPP TS 23.040 / ETSI TS 123 040, [Technical realization of the Short Message Service](https://www.etsi.org/deliver/etsi_ts/123000_123099/123040/04.10.00_60/ts_123040v041000p.pdf).

• Attribuez à l’OTP une expiration vérifiable par le vérificateur.
• Définissez une expiration d’utilité d’envoi qui ne permette pas l’expédition de codes déjà expirés ou pratiquement expirés.
• Ne traitez pas un DLR comme une preuve que le code a été vu, saisi ou accepté.
• Émettez une nouvelle opération uniquement après une nouvelle demande ou dans le cadre d’un flux contrôlé.
• Dans le cadre applicable de NIST, ne réinitialisez pas les contrôles des tentatives échouées simplement en générant un nouveau code.

Coordonnez les files d’attente, les TPS et les tentatives avec le temps restant

Une file d’attente peut transformer un message valide lors de sa création en message inutile avant son émission. Cela arrive lorsque les tâches s’accumulent, que des limites de TPS sont appliquées, qu’une réponse amont est attendue ou qu’une tentative est programmée sans vérifier l’expiration d’utilité.

La planification doit reposer sur le temps restant, et pas uniquement sur l’ancienneté ou la priorité. Un message doté d’une fenêtre courte exige une décision précoce : l’envoyer s’il peut l’être dans le cadre de la politique, le prioriser lorsque cela est légitime et sûr, ou le finaliser avant qu’il ne consomme davantage de ressources. Il n’est pas correct de le conserver indéfiniment au seul motif qu’il n’a pas encore reçu de réponse finale.

La spécification SMS prévoit des tentatives après des conditions temporaires, ainsi qu’un mode à tentative unique. Le choix ne doit pas être automatique pour tous les cas. Une tentative peut être raisonnable lorsque l’information reste pertinente et qu’il existe suffisamment de temps ; elle peut être préjudiciable lorsque le contenu dépend d’un état qui évolue rapidement.

La référence ETSI/3GPP citée est utilisée ici pour les concepts de période de validité et de tentatives ; elle ne prétend pas couvrir tous les comportements modernes des opérateurs.

Référence : 3GPP TS 23.040 / ETSI TS 123 040, [Technical realization of the Short Message Service](https://www.etsi.org/deliver/etsi_ts/123000_123099/123040/04.10.00_60/ts_123040v041000p.pdf).

• Calculez le temps restant avant la mise en file d’attente et avant chaque tentative.
• Évitez de programmer une tentative dont l’exécution prévue intervient après l’expiration d’utilité.
• N’appliquez des tentatives qu’en présence de conditions transitoires et selon une politique explicite pour chaque cas d’usage.
• Envisagez une seule tentative lorsque le risque de livraison tardive dépasse l’avantage d’insister.
• Arrêtez les tentatives à réception d’une annulation de l’opération, d’une mise à jour qui remplace le message ou d’une expiration d’utilité.

Interprétez les DLR comme des signaux de transport, et non comme une preuve d’usage

Les états de livraison sont nécessaires aux opérations, mais ils ne doivent pas être interprétés au-delà de leur portée. Les noms, la source de la confirmation et la signification exacte de chaque état dépendent de l’intégration, du fournisseur, de l’opérateur et de la route. Ils doivent être interprétés conformément à la documentation technique et contractuelle applicable.

Certaines intégrations peuvent utiliser des libellés tels que « queued », « sent », « delivered », « undelivered » ou « failed ». Ces libellés sont des exemples de taxonomie de fournisseur et non des états SMS universels ; ils peuvent avoir des significations différentes selon le fournisseur. Ils doivent donc être interprétés selon la sémantique documentée de l’intégration concernée.

Un DLR indiquant une livraison ne démontre pas qu’une personne a lu, compris ou utilisé le SMS. Les rapports de livraison SMS standardisés ne fournissent pas de preuve de lecture. Il ne faut pas non plus supposer qu’un DLR livré garantit universellement que le contenu était visible sur l’appareil ou qu’il a produit l’action attendue.

Le système doit donc séparer l’état externe de transport du résultat métier. Pour un OTP, par exemple, les événements pertinents sont au minimum la livraison signalée, la tentative de validation et l’acceptation ou le rejet du secret. Aucun ne doit se substituer aux autres.

• Les libellés d’état, tels que « queued », « sent », « delivered », « undelivered » ou « failed », peuvent avoir des significations différentes selon le fournisseur.
• Interprétez chaque état selon la documentation technique et contractuelle applicable à l’intégration.
• Un état « delivered » peut représenter une confirmation de livraison disponible dans la chaîne de transport ; il n’équivaut pas à une lecture ou à un usage.
• Un état « undelivered » ou « failed » peut signaler une non-livraison ou une impossibilité d’envoi ; conservez le motif disponible selon l’intégration.
• Résultat métier : état indépendant, tel que code accepté, opération finalisée, alerte prise en compte ou action non réalisée.

Lorsque l’utilité expire, finalisez l’opération avec une cause explicite

Un message en attente dont l’utilité a expiré ne doit pas demeurer sans état final explicite dans la file d’attente ni être classé uniquement avec un état technique externe. La plateforme a besoin d’un état interne final qui explique la décision : par exemple, « supprimé en raison de l’expiration d’utilité », avec l’heure et la règle qui l’ont motivée.

L’action ultérieure dépend du type de trafic. Pour un OTP ou une récupération, supprimez le message en attente et ne prolongez pas la durée de vie du secret. Pour une alerte qui reste pertinente, générez une mise à jour valide plutôt que d’insister avec le texte d’origine. Pour une campagne avec consentement, évitez de renvoyer automatiquement un contenu dont l’opportunité est déjà terminée.

Si la plateforme a déjà remis le message à un fournisseur ou au réseau, elle ne pourra peut-être pas garantir une annulation effective. C’est pourquoi la suppression avant envoi est le contrôle principal. Après la remise, enregistrez l’état connu, préservez l’incertitude et évitez qu’un DLR ultérieur ne modifie rétroactivement la décision métier.

• Annuler : si l’intégration et l’état de la tâche permettent encore de la retirer avant l’émission.
• Supprimer : finaliser dans sa propre file d’attente en raison de l’expiration d’utilité, sans l’envoyer au saut suivant.
• Réémettre : créer une nouvelle communication uniquement si le cas d’usage le justifie encore, avec un contenu actualisé.
• Escalader : enquêter sur les accumulations, les tentatives inhabituelles, les DLR incohérents ou les expirations répétées par destination, route ou fournisseur.

Enregistrez les données minimales pour auditer chaque décision

La politique n’est vérifiable que si chaque message laisse une chronologie suffisante pour reconstituer ce qui a été décidé et pourquoi. Les callbacks de livraison sont asynchrones ; l’ordre d’arrivée d’un DLR ne doit donc pas se substituer aux horodatages de création, d’acceptation, d’émission et d’expiration.

Utilisez un identifiant de corrélation stable pour relier l’opération métier à chaque tentative de transport. Distinguez l’identifiant interne, les identifiants de fournisseur lorsqu’ils existent et les identifiants de tentative. Cela permet d’analyser les doublons, les tentatives, les suppressions et les événements tardifs sans confondre des opérations distinctes.

Pour l’audit opérationnel, utilisez des journaux dotés de contrôles d’intégrité, d’une traçabilité des modifications, d’une rétention définie et d’un accès restreint. Évitez de stocker davantage de contenu personnel que nécessaire et appliquez les exigences pertinentes en matière de confidentialité, de protection des données, de conservation, de rectification et de suppression. L’essentiel est de pouvoir démontrer la politique appliquée, la séquence des états et le motif de la décision finale.

• Identifiant de corrélation de l’opération et type de cas d’usage.
• Identifiant interne du message, identifiants de fournisseur et de chaque tentative lorsqu’ils existent.
• Heure de création, d’acceptation, d’entrée et de sortie de file, d’émission et de réception de chaque DLR.
• Expiration technique configurée, expiration du contenu et échéance d’utilité.
• État technique signalé, état interne final et horodatage de chaque transition.
• Décision de tentative, d’annulation ou de suppression, avec son motif et la règle appliquée.
• Résultat métier, lorsqu’il s’applique, sans le déduire d’un DLR.