DLR tardifs en SMS A2P : définir une fenêtre d’observation et clôturer les messages sans perdre la traçabilité

Qu’est-ce qu’un DLR tardif dans une chaîne SMS A2P ?

Un accusé de réception de livraison, ou DLR, est un événement de statut relatif à un SMS précédemment soumis. Dans SMPP, lorsqu’il a été demandé via registered_delivery, le SMSC peut envoyer cet accusé à l’ESME par deliver_sm. Il ne s’agit pas de la réponse synchrone à submit_sm et il ne doit pas être traité comme tel.

Un DLR tardif est un accusé qui arrive après le moment où une application, une équipe opérationnelle ou une équipe de support attendait de prendre une décision. Il peut apparaître parce que le cycle du message traverse plusieurs systèmes et parce qu’il peut exister des tentatives de livraison intermédiaires. SMPP prévoit, par exemple, qu’une tentative échoue alors que le SMS reste retenu pour de nouvelles tentatives ; la prise en charge concrète de ces notifications dépend de l’implémentation du SMSC et du fournisseur.

Le retard de l’événement n’invalide pas l’événement en lui-même. Il indique que la décision opérationnelle de l’entreprise et le cycle de notification de la chaîne de livraison n’étaient pas nécessairement synchronisés. Il est donc préférable de concevoir une clôture opérationnelle réversible du point de vue de l’interprétation, mais non destructive du point de vue des données.

• Ne confondez pas la réponse d’acceptation de l’envoi avec un DLR.
• Ne considérez pas l’absence de callback comme une preuve automatique d’échec final.
• Conservez l’événement brut, même s’il arrive après la clôture opérationnelle.
• Maintenez distinctes la sémantique reçue du fournisseur et la classification interne.

Trois horloges à ne pas confondre

La gestion des DLR tardifs commence par la séparation de trois contrôles qui répondent à des questions différentes. S’ils sont utilisés comme s’ils étaient identiques, cela entraîne des clôtures prématurées, des expirations mal interprétées et des diagnostics peu fiables.

Le délai d’expiration de l’API détermine combien de temps l’application attend une réponse technique à sa requête. S’il expire, l’application doit résoudre l’incertitude liée à cette requête au moyen d’un identifiant de corrélation, d’une consultation de statut ou d’une stratégie de nouvelle tentative sûre. Il ne détermine ni combien de temps le SMS peut être livré ni combien de temps un DLR peut arriver.

La période de validité détermine jusqu’à quand un centre de service peut conserver un message afin de tenter sa livraison. Dans SMPP, validity_period représente l’heure d’expiration après laquelle le SMSC doit supprimer le message s’il n’a pas été livré. Dans 3GPP, la validité peut être exprimée dans des formats relatif, absolu ou amélioré. L’expiration de validité est une issue réseau ; elle ne doit pas être déduite simplement parce qu’aucun callback n’est arrivé.

La fenêtre d’observation du DLR est une politique opérationnelle propre à l’entreprise. Elle définit pendant combien de temps une issue est attendue pour alimenter les flux métier, les alertes, le support ou les rapports opérationnels. Elle n’est pas définie par le protocole et ne doit pas être assimilée au délai d’expiration ni copiée mécaniquement de la période de validité.

• Délai d’expiration de l’API : limite d’attente d’une réponse technique.
• Validité du message : limite de conservation et de tentatives de livraison dans la chaîne concernée.
• Fenêtre d’observation : limite interne permettant de décider d’un statut opérationnel, et non de supprimer des preuves.
• Période de réconciliation : intervalle ultérieur pour récupérer ou vérifier les événements manquants et les changements tardifs.

Pourquoi « accepté » ou « envoyé » ne confirme pas la livraison

Un statut d’acceptation ou d’envoi doit être décrit avec précision. Dans une sémantique de fournisseur documentée, sent signifie que l’opérateur amont le plus proche a accepté le message. Cela n’équivaut pas à une confirmation de livraison à destination.

Même lorsqu’un DLR indique livré, la communication doit conserver la portée réelle de la preuve. La spécification 3GPP distingue un message reçu par le SME d’un message retransmis par le centre de service sans que celui-ci puisse en confirmer la livraison. De plus, la preuve qu’un fournisseur peut exposer dépend de la confirmation disponible depuis l’opérateur et, lorsqu’elle existe, depuis le terminal.

Par conséquent, un statut delivered doit être enregistré comme la confirmation de livraison rapportée par la chaîne disponible, et non comme une preuve universelle, indépendante ou équivalente à la lecture par la personne destinataire. La lecture, la compréhension et la réalisation d’une action dans un flux métier sont des faits distincts du DLR.

• Accepté : la requête ou le message a été admis à un point de la chaîne.
• Envoyé : peut refléter un transfert ou une acceptation en amont, selon la sémantique documentée.
• Livré : reflète une confirmation rapportée, dont la portée dépend de la preuve disponible.
• Lu, utilisé ou converti : nécessitent des signaux indépendants provenant de l’application ou de l’utilisateur.

Comment modéliser les statuts internes sans écraser les preuves

Les callbacks sont asynchrones et le statut d’un message peut évoluer au cours de son cycle de vie. Le statut brut d’un fournisseur ne devrait donc pas être le seul champ qui pilote les opérations. Il est préférable de maintenir un historique immuable des événements et une vue interne calculée pour chaque message.

Un modèle pratique peut utiliser les statuts en attente, provisoire, final et mis à jour tardivement. Ces noms décrivent la position opérationnelle de l’entreprise ; ils ne remplacent pas la sémantique d’origine du DLR. L’enregistrement doit conserver à la fois l’événement reçu et la règle utilisée pour l’interpréter.

En attente peut représenter l’existence d’une acceptation technique ou l’absence d’issue suffisamment établie. Provisoire indique qu’une action métier ou de support a été prise dans un contexte d’incertitude explicite. Final identifie une issue reçue et classifiée selon les règles en vigueur. Mis à jour tardivement indique qu’un événement ultérieur a modifié la vue calculée ou apporté une information pertinente après la clôture opérationnelle.

Il n’est pas souhaitable de remplacer un statut antérieur ni de supprimer des événements parce qu’ils paraissent redondants. Conservez la séquence et calculez la vue actuelle avec des règles versionnées. Vous pourrez ainsi expliquer pourquoi un message a été clôturé à un moment donné et pourquoi son interprétation a été mise à jour ultérieurement.

• Événement brut : contenu reçu, identifiant, source et heure de réception.
• Statut normalisé : traduction contrôlée de la sémantique externe.
• Statut opérationnel : en attente, provisoire, final ou mis à jour tardivement.
• Motif de transition : règle appliquée, version de la règle et acteur en cas d’intervention manuelle.
• Statut de réconciliation : confirmé par les événements reçus, consulté, en attente de révision ou présentant une divergence.

Définir les fenêtres selon le cas d’usage

Il n’existe pas de durée universelle pour une fenêtre d’observation. Elle doit découler de l’objectif du message, de l’impact de l’attente, de la validité configurée, des signaux historiques disponibles et de la capacité réelle à réconcilier et traiter les exceptions.

Pour les OTP, la durée de validité fonctionnelle du code doit être décidée par la logique d’authentification. Le DLR apporte de l’observabilité et du diagnostic, mais il ne doit pas bloquer l’expiration du code ni le flux d’authentification. Définissez la fenêtre pour détecter les incidents, orienter des nouvelles tentatives sûres ou informer le support, sans en faire la source de vérité sur la validité du code d’accès.

Pour les notifications transactionnelles, la fenêtre peut être alignée sur le moment où le destinataire doit agir et sur les obligations internes de prise en charge. Si aucune issue n’existe à la clôture, le statut doit communiquer l’incertitude et déclencher le processus prévu, sans présumer d’une livraison ni d’un échec définitif.

Pour les messages non urgents, une fenêtre plus large peut être raisonnable si l’objectif tolère une livraison différée. Néanmoins, la fenêtre doit rester indépendante de la conservation dans les réseaux ultérieurs : une plateforme peut appliquer sa propre validité tant que le message y demeure et, une fois transféré à l’opérateur, celui-ci peut continuer à le mettre en file d’attente plus longtemps.

• OTP : séparez toujours l’expiration du code, la validité du SMS et le suivi du DLR.
• Transactionnel : définissez des actions de support ou des canaux alternatifs lorsque l’incertitude persiste.
• Non urgent : ne tolérez une observation plus longue que si le cas d’usage et la politique le justifient.
• Tous les cas : conservez une réconciliation après la clôture opérationnelle.

Critères pour choisir une fenêtre d’observation

La décision doit être documentée et révisable. Évitez de fixer une valeur unique sans observer le comportement des événements sur vos propres destinations, opérateurs, routes, types d’expéditeur et contenus légitimes. Les données historiques servent à guider une politique ; elles ne transforment pas un comportement passé en garantie future.

Analysez la répartition des délais entre l’acceptation initiale, les statuts intermédiaires et les issues reçues. Segmentez l’analyse selon les attributs opérationnels autorisés et nécessaires au service, sans utiliser cette segmentation pour masquer des problèmes ni envoyer du trafic non conforme.

La fenêtre doit être cohérente avec l’exigence de service. Si une opération doit décider avant qu’une preuve suffisante puisse normalement exister, elle doit intégrer l’incertitude dans son flux : par exemple, afficher un statut en attente, appliquer une vérification supplémentaire ou utiliser un canal alternatif conformément à la politique applicable.

La capacité de support compte également. Une fenêtre courte peut réduire la file visible, mais augmente le risque de classifier trop tôt. Une fenêtre large réduit certaines clôtures prématurées, mais peut retarder les alertes et accroître le nombre de messages en suivi. La politique doit expliciter ce compromis.

• Comportement historique des DLR par destination, opérateur, route et type de trafic.
• Criticité et délai réel du cas d’usage.
• Période de validité configurée et sémantique documentée de chaque connexion.
• Taux d’événements tardifs, dupliqués, absents ou reçus dans le désordre.
• Capacité de consultation, de réconciliation, de traitement des incidents et de communication client.
• Exigences contractuelles, réglementaires et applicables de conservation des enregistrements.

Concevoir une politique de clôture et de conservation des données

Une politique de clôture définit ce qui se produit lorsque la fenêtre d’observation prend fin sans issue concluante, quels événements peuvent modifier ultérieurement la vue et qui peut approuver les exceptions. La clôture doit être une décision opérationnelle auditable, et non la suppression du message du système.

Établissez une taxonomie claire pour les cas sans issue. Par exemple, « clôturé provisoirement sans DLR final reçu » est plus explicite que « échec » lorsqu’aucune erreur finale n’a été rapportée. Réservez les statuts définitifs aux preuves qui soutiennent réellement cette classification.

La politique doit indiquer qui est responsable des règles : opérations, produit, ingénierie, délivrabilité ou comité commun, selon le modèle organisationnel. Elle doit également définir un processus de changement : motif, évaluation d’impact, version, date d’effet, approbation et plan de réversibilité.

Documentez les exceptions prévisibles, telles que les incidents de connectivité des callbacks, les changements d’intégration, les divergences identifiées lors de la réconciliation ou les routes ayant des sémantiques différentes. Une exception ne doit pas modifier rétroactivement l’historique brut ; elle doit modifier de façon traçable l’interprétation ou le traitement opérationnel.

• Identifiant interne unique du message.
• Identifiant retourné par le fournisseur ou la connexion, lorsqu’il existe.
• Identifiants de compte, de service ou de route disponibles et pertinents.
• Origine, destination et attributs nécessaires à la corrélation, protégés conformément à la politique de données applicable.
• Statut initial, événements ultérieurs, payload brut conservé de manière sécurisée et statut normalisé.
• Heure de requête, d’acceptation, de réception du callback et, lorsqu’elle est disponible, heure de finalisation indiquée par le DLR.
• Règle, version et motif de chaque transition interne.
• Résultat des consultations de réconciliation et référence de l’incident, le cas échéant.

DLR dupliqués, reçus dans le désordre ou contradictoires

La réception de plusieurs événements pour un même message ne doit pas obliger à en choisir un et à écarter les autres. Dédupliquer afin d’éviter des actions répétées est utile ; supprimer des doublons apparents élimine des preuves qui peuvent être nécessaires au diagnostic.

Utilisez une clé d’idempotence fondée sur les identifiants disponibles et sur une empreinte de l’événement. Si vous recevez deux événements équivalents, vous pouvez les marquer comme répétés dans la vue opérationnelle, tout en conservant les deux ou une référence vérifiable à l’événement d’origine conformément à la politique de conservation. L’idempotence doit s’appliquer en particulier aux actions annexes, telles que les notifications, la facturation interne ou l’ouverture de tickets.

Pour les événements reçus dans le désordre, distinguez l’heure de réception du callback et l’heure que le DLR, lorsqu’elle est disponible, attribue à l’issue. SMPP définit done date comme la date et l’heure auxquelles le message a atteint son statut final. Cet horodatage peut aider à ordonner les preuves, mais il ne remplace pas l’heure à laquelle votre système les a reçues.

Face à des contradictions, ne forcez pas une conclusion sans règle explicite. Marquez la divergence, conservez tous les événements, appliquez une priorité documentée uniquement à la vue matérialisée et, si nécessaire, consultez les enregistrements disponibles ou escaladez au responsable de la connexion. Les règles doivent pouvoir évoluer, car les champs des callbacks et leurs propriétés peuvent varier au fil du temps.

• N’écrasez pas le dernier statut sans conserver la séquence précédente.
• Utilisez un traitement idempotent pour éviter les effets secondaires dupliqués.
• Stockez séparément l’horodatage de réception et celui déclaré par le DLR.
• Classez les conflits pour révision plutôt que de les masquer.
• Versionnez les règles de priorité et testez les changements avant de les appliquer.