Comment enquêter sur les écarts de DLR en SMS A2P sans confondre livraison et réception humaine

La bonne question : que démontre réellement chaque élément de preuve ?

Une enquête sur des écarts de DLR en SMS A2P commence par la séparation de faits souvent regroupés dans un même champ d’état. L’acceptation de l’envoi, la progression dans la chaîne, l’état communiqué par un SMSC et l’observation sur un terminal ne sont pas équivalents.

En SMPP, un submit_sm_resp réussi indique que le SMSC a traité l’opération et attribué un message_id. Selon l’API HTTP, une réponse de création ou d’acceptation accompagnée d’un identifiant atteste généralement d’une acceptation technique à ce point de la chaîne. Ces éléments n’attestent pas de la livraison à destination.

Les états ultérieurs arrivent de manière asynchrone. En SMPP, un reçu provenant du SMSC peut être reçu via deliver_sm ou data_sm. Ce DLR exprime l’état conservé ou communiqué par le SMSC. Il ne doit pas être automatiquement attribué au terminal, à l’utilisateur ou à tous les maillons précédents.

Une observation indépendante — par exemple, une réception enregistrée par un appareil de test contrôlé — constitue un élément de preuve distinct. Sa portée dépend du contrôle de l’appareil et de la fiabilité de la méthode de capture. Elle peut renforcer ou contredire le DLR, mais elle ne prouve pas à elle seule l’identité de la personne qui utilise l’appareil et ne permet pas de généraliser le résultat à l’ensemble d’une route.

• Acceptation API ou submit_sm_resp : le point récepteur a accepté ou traité la demande et a renvoyé un identifiant.
• État temporaire : renseigne sur une progression, une file d’attente ou un transit ; il ne clôt pas nécessairement le cycle.
• DLR final : déclaration technique de la chaîne selon la sémantique documentée par la connexion.
• Observation indépendante : signal distinct obtenu hors du flux DLR ; sa méthode et son périmètre doivent être documentés.
• Lecture humaine : elle ne peut pas être déduite universellement d’un DLR SMS.

Pourquoi DELIVRD ne prouve ni la lecture ni l’identité

SMPP définit DELIVERED comme une valeur de message_state. Dans le format textuel habituel de certains DLR, la représentation peut apparaître sous la forme DELIVRD. Le contenu du DLR traditionnel peut toutefois être propre au fournisseur du SMSC ; il faut donc consulter la spécification applicable et la documentation officielle de chaque connexion avant de mapper des valeurs telles que DELIVRD.

La 3GPP distingue explicitement la réception par la station mobile de la remise à l’utilisateur. Même lorsqu’une confirmation de la station mobile existe, elle ne démontre pas qu’une personne a vu, ouvert ou compris le message. Les SMS ne fournissent pas non plus universellement un accusé de lecture.

L’état communiqué comme delivered peut provenir de la confirmation d’un opérateur en amont et n’incorporer une confirmation du terminal que lorsqu’elle est disponible. L’origine exacte doit être conservée dans chaque événement au lieu d’être transformée en une affirmation plus forte.

L’identité humaine du destinataire n’est pas davantage prouvée. Une destination technique ou un appareil peut recevoir le message sans démontrer qui contrôle le numéro, qui détient le terminal ou qui visualise le contenu. Un OTP doit être traité selon la conception de sécurité complète du service, et non comme une preuve d’identité fondée uniquement sur le DLR.

Il convient aussi d’éviter une confusion terminologique : l’état SMPP ACCEPTED ne signifie pas une lecture ordinaire ni l’acceptation initiale du transport. La spécification le décrit comme une lecture manuelle au nom de l’abonné par le service client. L’acceptation initiale de l’envoi est enregistrée séparément.

• Écrire « DLR communiqué comme DELIVRD » plutôt que « utilisateur atteint » lorsqu’aucun élément de preuve supplémentaire n’est disponible.
• Conserver le fournisseur, la connexion et la version du mapping ayant converti la valeur d’origine en état interne.
• Ne pas présenter DELIVRD comme une lecture, une identité, un consentement ou une garantie universelle de réception sur le terminal.
• Conserver séparément delivered, observation sur appareil et read lorsqu’un canal prend en charge des événements de lecture.

Modèle minimal de traçabilité de bout en bout

Une corrélation fiable exige un enregistrement par message logique, par segment lorsqu’il existe une concaténation, et par événement reçu. Il doit conserver l’identifiant interne avec le message_id ou l’identifiant attribué par chaque SMSC, API ou partenaire. Dans le format de DLR applicable à la connexion, le champ id renvoie généralement à l’identifiant attribué au message initial par le SMSC ; vérifiez le format du fournisseur.

Il ne faut pas corréler uniquement selon l’adresse du SMSC. La 3GPP avertit que les architectures de résilience et d’équilibrage de charge peuvent faire provenir un rapport d’une adresse différente de celle utilisée pour l’envoi initial.

Normalisez les enregistrements dans un schéma commun, tout en préservant l’événement original et sa source. La normalisation facilite les requêtes ; la donnée brute permet d’auditer les erreurs d’analyse et les changements de format. La destination peut être conservée dans une représentation normalisée fondée sur E.164, ainsi qu’avec la valeur originale reçue.

Chaque horodatage doit inclure sa sémantique, sa source et son lien explicite avec l’UTC via Z ou un décalage. Ne remplacez pas l’heure déclarée par le fournisseur par l’heure de réception du callback. Conservez également l’observation indépendante comme troisième instant. Avant d’interpréter une séquence impossible, écartez l’hypothèse d’horloges désynchronisées.

• Identifiant interne du message logique et identifiant de chaque segment.
• Identifiant de requête, message_id du SMSC ou du fournisseur, ainsi qu’identifiant d’événement ou de callback, s’il existe.
• Horodatage d’envoi local, horodatage déclaré par la source, réception du callback et observation indépendante.
• Fuseau horaire ou décalage, précision disponible, système source et horloge ayant produit chaque horodatage.
• Fournisseur, connexion, route déclarée, destination d’origine et normalisée, opérateur observé ou déclaré et expéditeur.
• Contenu normalisé ou empreinte contrôlée, encodage, longueur et nombre de segments, selon la politique de conservation applicable.
• État et erreur d’origine, état interne normalisé et version du mapping appliqué.
• Numéro de tentative, cause du retry, environnement de test ou de production et exclusions analytiques.

Taxonomie reproductible des écarts

Une étiquette précise évite que des problèmes d’observabilité soient prématurément attribués à la route. Chaque cas doit pouvoir être associé à une règle vérifiable, une fenêtre temporelle documentée et un état d’enquête.

La taxonomie interne doit distinguer les états temporaires, finaux et non concluants. SMPP définit notamment ENROUTE, DELIVERED, EXPIRED, DELETED, UNDELIVERABLE, ACCEPTED, UNKNOWN et REJECTED, mais la sémantique effective doit être vérifiée dans la documentation de la connexion.

• Absence : aucun DLR corrélable n’existe dans la fenêtre observée. Cela n’équivaut pas automatiquement à un échec de livraison.
• Doublon : plus d’une copie du même événement ou état est reçue. Dédupliquez par identifiant et fenêtre temporelle avant agrégation.
• Retard : le DLR arrive après le délai attendu pour ce segment opérationnel, sans que cela modifie la signification de l’état.
• Contradiction : deux sources ou événements finaux attribuent des résultats incompatibles au même message ou segment.
• Non corrélable : un DLR existe, mais son identifiant ne permet pas de le relier de manière sûre à l’envoi initial.
• Séquence invalide : une transition enfreint la machine à états documentée ou les heures semblent impossibles.
• Résultat partiel : un message concaténé comporte des segments réussis et des segments en échec ; cela ne doit pas être masqué par un seul résultat simplifié.
• Taxonomie inconnue : un état ou code non prévu dans la version active du mapping apparaît.

Procédure d’enquête étape par étape

Commencez par délimiter l’incident sans mélanger des populations différentes. Définissez le début et la fin, le cas d’usage, la destination, l’opérateur, l’expéditeur, le fournisseur, la connexion, la route déclarée, le type de trafic, l’encodage et la condition exacte d’inclusion. Consignez également la taille de l’échantillon et les biais possibles.

Validez ensuite l’observabilité. Vérifiez que le point de terminaison des callbacks était accessible, qu’il persistait la requête avant de répondre, qu’il acceptait le schéma reçu et qu’il renvoyait une réponse HTTP valide. Un validateur trop strict peut rejeter de nouveaux champs. Examinez les files d’attente, les erreurs d’ingestion, le stockage, les retries, la déduplication et la synchronisation des horloges.

Reconstruisez ensuite la chronologie par message et par segment : requête, réponse initiale, états temporaires, DLR final, retries techniques et observation indépendante. Comparez les valeurs originales et transformées, sans ordonner aveuglément des événements produits par des horloges différentes.

Enfin, attribuez le domaine le plus probable : intégration interne, observabilité, mapping des états, connexion du fournisseur, route déclarée, réseau ou destination. Si les éléments de preuve ne permettent pas de l’isoler, conservez la classification comme indéterminée plutôt que de forcer une cause.

• 1. Figer le périmètre, la requête et les exclusions afin de rendre l’analyse reproductible.
• 2. Sélectionner des exemples représentatifs et conserver leurs enregistrements d’origine.
• 3. Vérifier la réception, la réponse et la persistance des callbacks.
• 4. Réconcilier les messages en attente via le mécanisme officiel de consultation, si la connexion le propose.
• 5. Corréler tous les identifiants sans dépendre uniquement de la destination ou de l’adresse du SMSC.
• 6. Examiner les horodatages, décalages, dérives d’horloge et la sémantique de chaque heure.
• 7. Appliquer la bonne version du mapping et contrôler les transitions.
• 8. Séparer l’intégration, la route et la destination ; documenter l’incertitude et les preuves manquantes.

Timeouts, états temporaires et clôture opérationnelle

Un timeout d’API, de connexion ou de callback ne démontre pas que le SMS n’a pas été livré. L’opération a pu se poursuivre après la perte de la réponse. Recherchez le reçu ultérieur et, lorsqu’une prise en charge officielle existe, réconciliez au moyen d’une consultation d’état.

Les erreurs temporaires et états en transit ne doivent pas être convertis en échecs finaux tant que les tentatives du centre de service se poursuivent ou que la validité applicable reste ouverte. De même, un état en attente ne doit pas être transformé en delivered pour compléter un rapport.

Définissez une fenêtre de clôture liée au cas d’usage et à la validité configurée. Pour un OTP, l’utilité peut prendre fin rapidement, même si l’état technique arrive plus tard. Une notification non urgente peut admettre une autre fenêtre. L’expiration fonctionnelle, la clôture analytique et l’état technique sont des champs distincts.

Le TP-Discharge-Time ne doit pas non plus toujours être interprété comme une heure de livraison réussie : selon l’état, il peut représenter la livraison, la dernière tentative ou le traitement du message par le centre de service.

• Conserver l’état technique d’origine après la clôture opérationnelle.
• Étiqueter « sans DLR à la clôture » au lieu de reclasser automatiquement le message comme failed.
• Autoriser les réconciliations tardives sans réécrire silencieusement les rapports déjà émis.
• Versionner la logique de clôture et expliquer son lien avec la validité et le cas d’usage.

Tests synthétiques et trafic de production

Les tests synthétiques permettent de contrôler l’appareil, l’heure, le contenu, l’expéditeur et la méthode d’observation. Ils sont utiles pour reproduire des problèmes et comparer les DLR à la réception observée. Toutefois, un échantillon contrôlé ne reproduit pas nécessairement la distribution des destinations, terminaux, disponibilités, filtres et profils du trafic réel.

Le trafic de production apporte de l’échelle et de la diversité, mais offre généralement moins de contrôle sur le terminal et ne doit pas servir à déduire une lecture ou une identité. Il doit en outre être traité conformément aux règles applicables en matière de consentement, de finalité et de conservation des enregistrements.

Toute donnée illustrative doit être clairement identifiée comme telle et ne doit pas être interprétée comme une donnée commerciale en temps réel.

Ne mélangez pas les tests et la production dans un même taux. Marquez séparément le trafic synthétique, les retries techniques et les messages concaténés. Si des sources sont comparées, documentez leurs différences de sélection, de volume et de méthode.

• Synthétique : davantage de contrôle et meilleure reproductibilité ; représentativité universelle plus faible.
• Production : plus grande diversité ; moindre certitude sur ce qui s’est produit sur le terminal.
• Utiliser des messages légitimes, consentis et conformes à la réglementation applicable.
• Ne pas extrapoler un appareil de test à une route entière sans preuves suffisantes.

Des métriques utiles sans créer de fausse certitude

Ne réduisez pas l’acceptation, la couverture des DLR, la latence et le résultat à un seul score. Ce sont des dimensions différentes. La couverture des DLR peut être définie comme la proportion de messages éligibles ayant au moins un événement corrélable ; elle doit rester distincte de la proportion communiquée comme delivered.

Calculez la latence par percentiles et selon des jalons clairement définis. Par exemple, l’acceptation jusqu’à la réception du callback n’est pas équivalente à submit date jusqu’à done date. Indiquez la source des deux extrémités, le décalage et le traitement des valeurs manquantes.

Avant agrégation, dédupliquez selon l’identifiant de message ou d’événement et une fenêtre temporelle. Excluez ou marquez séparément les tests, les retries et les messages concaténés afin d’éviter les doubles comptes. Pour les messages concaténés, mesurez également les segments réussis et en échec.

Construisez des références segmentées par destination, opérateur, expéditeur, type de trafic, route déclarée, plage comparable et version d’intégration. Analysez les changements durables par rapport aux variations ponctuelles. Avec de faibles volumes, indiquez la taille de l’échantillon et l’incertitude plutôt que de produire des classements apparemment précis.

Examinez régulièrement la qualité des données elles-mêmes : callbacks perdus, horloges désynchronisées, champs incomplets, identifiants réutilisés, horodatages futurs, erreurs d’ingestion, sauts impossibles et changements brusques de taxonomie.

• Couverture des DLR : messages éligibles disposant d’un DLR corrélable divisé par le nombre de messages éligibles.
• Cohérence : proportion d’événements respectant la corrélation, la taxonomie et la séquence définies.
• Latence : percentiles par paire de jalons et segment comparable, et non une simple moyenne.
• Ancienneté des messages en attente : distribution par intervalles depuis le jalon retenu.
• Non corrélés : proportion et volume de DLR sans lien sûr avec l’envoi.
• Contradictions et doublons : volume avant et après déduplication.
• Tableau de bord recommandé : distribution des états, évolution des percentiles, backlog par ancienneté, couverture et qualité des données.
• Note méthodologique visible : source, périmètre, exclusions, fenêtre, échantillon, version du mapping et limites.