Expiration et purge des files d’attente SMS A2P : éviter les livraisons tardives

Trois limites distinctes : utilité, file interne et expiration du fournisseur

L’expiration des SMS A2P ne se résume pas à un seul minuteur. Il est préférable de distinguer trois contrôles : l’échéance fonctionnelle, qui détermine jusqu’à quand le contenu est utile au destinataire ; la politique d’expiration de la file interne ou du broker ; et la période de validité demandée au fournisseur ou au centre de service.

Le TP-Validity-Period défini par la 3GPP indique pendant combien de temps le centre de service conserve le message avant que sa livraison soit effectuée. Il ne correspond pas au TTL de la file de l’application. De plus, la mise en œuvre et la portée d’une option d’expiration sur une plateforme varient selon les fournisseurs.

Par exemple, Twilio documente une période de validité correspondant à la durée pendant laquelle le message reste dans sa file d’envoi. Sa documentation précise qu’une fois le message transmis au réseau des opérateurs, celui-ci peut encore être mis en file d’attente et livré ultérieurement. Ce paramètre ne doit pas être interprété comme une garantie de livraison avant une heure limite.

• Échéance fonctionnelle : jusqu’à quand le destinataire aurait-il encore intérêt à recevoir ce message ?
• TTL interne : combien de temps le broker peut-il le conserver pour traitement ?
• Validité côté fournisseur : quelle étape le paramètre documenté pour cette connexion couvre-t-il ?
• Confirmez par écrit la signification, les limites et le comportement de chaque paramètre dans la documentation technique applicable.

Pourquoi le rétablissement d’une route peut libérer des messages obsolètes

Lorsqu’une connexion dispose d’une capacité limitée, certaines plateformes mettent les demandes en file d’attente pour les envoyer ultérieurement. Si la route redevient disponible, ces messages peuvent reprendre leur acheminement. À lui seul, un engorgement ne rend pas le contenu obsolète et ne garantit pas que le fournisseur le supprimera.

Avant d’envoyer un élément retenu, vérifiez son échéance fonctionnelle. Si elle est dépassée, ne le renvoyez pas simplement parce que la connexion a retrouvé de la capacité. L’expiration du broker peut aider, mais son application dépend du produit et de l’état du message. Par exemple, Azure Service Bus documente des particularités concernant les messages expirés et ceux qui sont déjà verrouillés ; elles ne doivent pas être généralisées à d’autres brokers.

• Vérifiez la validité fonctionnelle juste avant l’envoi, et pas seulement lors de la mise en file d’attente.
• Lorsqu’une route redevient disponible, vérifiez d’abord l’expiration, puis sélectionnez les messages admissibles.
• Mesurez l’ancienneté de la file et déclenchez des alertes ; la latence observée ne remplace pas une règle d’expiration.
• Vérifiez comment votre broker traite les messages expirés, verrouillés et placés dans la file d’attente des messages non traités.

Définissez des politiques par catégorie de trafic

Une durée unique ne convient pas à tous les cas. La règle doit découler de l’utilité temporelle du message et des exigences applicables, puis être traduite en une échéance vérifiable. Lorsque l’architecture le permet, configurez séparément l’expiration chez le fournisseur et l’expiration interne.

Pour les OTP, la norme NIST SP 800-63B-4 prévoit qu’une authentification hors bande doit être considérée comme invalide si elle n’est pas terminée dans les 10 minutes et que le secret ne doit être accepté qu’une seule fois. OWASP recommande également un TTL court, une utilisation unique, des limites de tentatives et l’invalidation après une vérification réussie. Cette limite d’authentification n’est ni une durée universelle pour une file d’attente ni une recommandation pour d’autres catégories de messages.

Les alertes transactionnelles et les messages non urgents nécessitent leurs propres règles. Définissez leur expiration en fonction de l’opération qu’ils signalent, des attentes de l’utilisateur et des obligations applicables. Si vous ne pouvez pas justifier une durée précise, ne la présentez pas comme une norme : documentez le critère et validez le comportement.

• OTP : le système d’authentification doit rejeter un code expiré et empêcher sa réutilisation, même si le SMS arrive plus tard.
• Alertes transactionnelles : définissez l’événement qui les rend obsolètes et la manière d’éviter une notification tardive qui contredirait l’état actuel.
• Messages non urgents : fixez une période de validité adaptée à leur objectif ; ne reprenez pas automatiquement la configuration des OTP.
• Pour toutes les catégories : respectez les exigences applicables en matière de consentement et de conformité, et ne renvoyez pas de messages promotionnels en dehors de l’autorisation prévue.

Concevez le cycle de vie et traitez avec prudence les états incertains

Modélisez le parcours au moyen d’états explicites : en file d’attente, admissible, transmis au fournisseur, accepté par l’opérateur, expiré, annulé et clôturé avec un résultat incertain. Les noms exacts varient ; suivez le contrat de votre plateforme et conservez la correspondance avec ses états.

L’acceptation d’une demande ne signifie pas que le SMS a déjà été livré. Dans la documentation de Twilio, par exemple, « sent » indique une acceptation par l’opérateur en amont, tandis que « delivered » dépend d’une confirmation ultérieure. Un DLR ou un callback est un signal du système concerné, pas une preuve indépendante que le destinataire a lu le message ni une garantie universelle de confirmation sur l’appareil.

En l’absence de résultat concluant, conservez l’état « incertain » jusqu’à la réception d’un événement ultérieur ou à la clôture du rapprochement selon une politique documentée. Évitez les nouvelles tentatives automatiques susceptibles de générer des doublons sans évaluation du risque.

• Enregistrez l’échéance fonctionnelle avec l’identifiant du message et vérifiez-la à chaque étape du traitement.
• Distinguez la demande acceptée, l’envoi à l’opérateur en amont et la livraison signalée ; ne les regroupez pas sous un unique état « réussi ».
• Définissez l’événement qui clôt une opération et la manière de rapprocher les cas sans DLR ou présentant des états contradictoires.
• Protégez les OTP : ne consignez pas leur valeur en clair dans les journaux d’audit habituels.

Changer de route ou purger : gérer les messages en cours d’acheminement

Une purge interne peut empêcher le traitement des messages encore contrôlés par votre système, mais il ne faut pas supposer qu’elle peut retirer un SMS déjà transmis au réseau. Les possibilités d’annulation dépendent du fournisseur et de l’état du message : la documentation de Twilio décrit, par exemple, l’annulation de certains messages programmés avant leur heure d’envoi ; cela ne constitue pas une possibilité générale d’annulation après transmission à l’opérateur.

Lors d’un changement de route, distinguez les éléments encore présents dans votre file de ceux déjà acceptés par le fournisseur. Pour les premiers, vérifiez l’échéance et décidez, selon les règles documentées, de les conserver, de les supprimer ou de les réacheminer. Pour les seconds, consultez les états et les reçus, mais précisez les limites de votre contrôle : le message peut continuer son parcours même si votre file locale a été purgée.

Lors d’une purge de grande ampleur, définissez le périmètre selon un identifiant, une catégorie de trafic, une route, une période ou un autre critère opérationnel vérifiable. Utilisez un mode de prévisualisation s’il est disponible et évitez de supprimer sans distinction les éléments dont l’état est incertain.

• Interrompez ou limitez les envois avant de modifier les règles, si la conception opérationnelle le permet.
• Classez les messages selon qu’ils sont encore en interne, transmis au fournisseur ou dans un état incertain.
• N’annulez à distance que si le fournisseur documente cette action pour l’état concerné.
• Ne prétendez pas qu’une purge empêchera la livraison de messages déjà acceptés par le réseau.

Rendez la purge vérifiable et conciliable

Une purge opérationnelle doit pouvoir être reconstituée : quels éléments ont été retirés, pour quelle raison, selon quel périmètre et avec quelle autorisation. Enregistrez les horodatages et les identifiants nécessaires pour relier la décision locale aux états du fournisseur et aux reçus reçus ultérieurement.

Il n’est pas nécessaire de stocker le corps du SMS pour que l’audit soit utile. Évitez en particulier d’enregistrer des OTP en clair. Si le broker permet de placer les messages expirés dans une file dédiée aux messages non traités, cela peut aider à leur examen et au rapprochement, mais cette fonction doit être explicitement activée et configurée ; son comportement dépend du broker.

• Consignez le motif, le périmètre de la purge, l’acteur ou le processus autorisé et les horodatages.
• Conservez les identifiants de corrélation et les états avant et après l’opération, avec un accès restreint.
• N’incluez pas systématiquement dans les journaux le contenu sensible ni les secrets d’authentification.
• Documentez la durée de conservation, les autorisations de purge et la procédure de rapprochement des messages expirés ou incertains.

Testez chaque connexion et chaque étape avant de vous fier à l’expiration

Un paramètre portant le même nom peut avoir des portées différentes selon les fournisseurs. Vérifiez la documentation de la connexion concernée et effectuez des tests contrôlés dans un environnement adapté et avec des destinataires autorisés. Ne transformez pas un résultat ponctuel en garantie pour d’autres opérateurs, routes ou états du réseau.

Observez séparément l’expiration de la file interne, la demande d’expiration adressée au fournisseur, les états d’acceptation et les reçus de livraison. Notez ce qui se passe pour les messages en file d’attente, envoyés et dont le résultat est incertain. Répétez les tests après tout changement important de configuration ou de connexion, en respectant les limites et conditions du fournisseur.

• Vérifiez les unités, la plage autorisée, la valeur par défaut et l’étape couverte par chaque paramètre.
• Testez les messages qui expirent avant leur envoi et ceux dont l’état change pendant le test.
• Comparez l’état local aux callbacks ou aux reçus, et documentez les cas sans confirmation concluante.
• Examinez les réserves propres au broker et au fournisseur ; ne généralisez pas les résultats d’une seule plateforme.

Liste de contrôle opérationnelle

Avant d’activer ou de modifier une politique, vérifiez que l’équipe sait identifier les messages expirés, les distinguer de ceux déjà en cours d’acheminement et expliquer les éléments de preuve disponibles à chaque étape. La revue doit également porter sur les autorisations, les alertes et la communication entre les équipes des opérations, de l’ingénierie et du produit.

Chaque catégorie de trafic dispose d’un critère d’expiration fonctionnelle documenté.

Le consommateur vérifie l’échéance avant l’envoi, y compris après le rétablissement d’une route.

Le TTL du broker et l’expiration du fournisseur sont documentés comme des contrôles distincts.

Les états d’acceptation, d’envoi, de livraison signalée et d’incertitude ne sont pas confondus.

• La purge a un périmètre, un motif, une autorisation, des horodatages et des identifiants permettant le rapprochement.
• Des alertes couvrent l’ancienneté de la file, son accumulation, les expirations et l’absence de confirmation, selon des seuils définis par l’équipe.
• Les changements opérationnels sont communiqués aux équipes concernées et s’accompagnent d’une procédure de retour arrière.