Horodatage des événements A2P SMS : réconcilier les heures de la plateforme, du fournisseur et des DLR
Un guide pratique pour enregistrer, comparer et auditer les heures des événements SMS sans confondre la réception d’un DLR avec une confirmation indépendante de livraison au terminal.
Pourquoi les heures enregistrées peuvent différer
Un envoi A2P peut générer des journaux dans plusieurs systèmes : l’application ou la plateforme à l’origine de l’envoi, le fournisseur qui reçoit le message, ainsi que les systèmes qui émettent ou transmettent un rapport d’état. Chaque journal peut correspondre à un moment différent et utiliser une source horaire, un fuseau ou un niveau de précision différents.
Ainsi, deux horodatages distincts ne prouvent pas à eux seuls qu’il y a une erreur. Pour les interpréter, il faut d’abord savoir quel événement chaque champ est censé représenter et quel système l’a généré. La documentation disponible pour cet article ne permet pas d’attribuer des définitions universelles aux horodatages ou aux DLR sur la base d’une spécification particulière ; convenez de ces sémantiques avec chaque fournisseur et consignez-les.
- Ne comparez pas une heure de création à une heure de réception comme si elles décrivaient le même événement.
- Consignez le système d’origine et la signification déclarée de chaque horodatage.
- Traitez la précision et la sémantique de chaque champ comme des propriétés à vérifier, et non comme des éléments à supposer.
Distinguez la création, l’envoi, l’acceptation et la réception du callback
Utilisez des noms d’événements explicites. À tout le moins, distinguez le moment où l’enregistrement ou la demande a été créé, celui où la plateforme a tenté de l’envoyer, celui où elle a reçu une réponse d’acceptation, l’heure d’événement déclarée par le fournisseur et le moment où le callback est arrivé dans votre système. Ne présumez pas qu’un message « accepté » a été livré au terminal.
Conservez séparément l’heure de l’événement communiquée par le fournisseur et l’heure à laquelle votre plateforme a reçu ce rapport. La première correspond à une déclaration du système qui émet l’événement ; la seconde consigne sa réception locale. Si le fournisseur ne précise pas ce que représente son horodatage, conservez-le comme donnée d’origine sans le réinterpréter.
- Définissez un dictionnaire des événements précisant leur nom, le système émetteur et leur signification.
- Enregistrez séparément l’horodatage déclaré par le fournisseur et l’horodatage de réception locale.
- Ne transformez pas un état d’acceptation ou la réception d’un rapport en affirmation de livraison au terminal.
Normalisez pour comparer, mais conservez la donnée d’origine
Pour faciliter les recherches et les comparaisons entre systèmes, adoptez une représentation horaire commune, par exemple UTC, et une convention de sérialisation sans ambiguïté. Avant de convertir une valeur, identifiez son fuseau horaire ou son décalage. Si cette information n’est pas disponible, consignez cette absence : ne supposez pas que l’heure correspond au fuseau du serveur ou de l’opérateur.
La normalisation ne doit pas écraser la valeur reçue. Conservez le texte ou la valeur d’origine, le fuseau déclaré, la source et la valeur normalisée dérivée. Vous pourrez ainsi vérifier les conversions, résoudre les écarts et reconstituer ce que chaque système a communiqué.
- Stockez la valeur d’origine sans la modifier.
- Consignez le fuseau horaire ou le décalage, et indiquez explicitement s’il est inconnu.
- Stockez la valeur normalisée dans un champ distinct et documentez la règle de conversion.
- N’inventez pas de précision : conservez le niveau de précision disponible et signalez s’il est inconnu.
Désynchronisation, précision inégale, doublons et événements hors séquence
Un horodatage ne suffit pas à diagnostiquer une horloge désynchronisée. Ne comparez les champs que lorsque leur signification et leur fuseau horaire sont connus, et consignez les écarts observés comme des indices, non comme une preuve automatique de leur cause. Si le système fournit des informations fiables sur la synchronisation ou la qualité de l’horloge, stockez-les séparément ; ne les déduisez pas d’une séquence qui semble inhabituelle.
Les callbacks peuvent arriver après d’autres événements ou être répétés. Concevez l’ingestion de façon à conserver les événements reçus, à reconnaître les doublons éventuels au moyen d’identifiants stables lorsqu’ils existent, et à garder l’historique des modifications. En l’absence d’identifiant approprié, ne déduisez pas que deux rapports correspondent au même événement simplement parce qu’ils partagent le même état et la même heure.
- Distinguez l’heure déclarée de l’événement de l’heure de réception locale.
- Consignez la précision déclarée ou disponible ; n’ajoutez pas de fractions de seconde absentes des données.
- Conservez les événements tardifs et hors séquence au lieu de les supprimer parce qu’ils sont arrivés après les autres.
- Utilisez les identifiants de message et d’événement lorsqu’ils sont disponibles, et documentez leurs limites.
- Ne supprimez pas les doublons de façon irréversible : conservez une trace de leur détection et de leur traitement.
Règles de réconciliation : établir une priorité sans fausse certitude
Il n’existe pas ici de règle universelle étayée permettant de classer temporellement tous les événements A2P SMS. Définissez des règles internes par type d’événement, en vous appuyant sur le contrat ou la documentation technique du fournisseur. Une réponse d’acceptation, un événement d’état communiqué par le fournisseur et la réception du callback doivent rester des faits distincts.
Lorsque deux sources divergent, évitez de choisir un seul horodatage comme étant « le vrai » sans justification documentée. Vous pouvez définir une heure de référence opérationnelle pour les rapports, mais conservez toutes les observations et indiquez le critère appliqué. Si la signification ou le fuseau horaire d’une donnée n’est pas clair, marquez la comparaison comme non concluante.
- Définissez les priorités en fonction de la sémantique de l’événement, et non du nom générique du champ.
- Consignez la règle appliquée, sa version et les sources prises en compte.
- Distinguez l’état calculé par votre plateforme des états reçus de tiers.
- Signalez les écarts non résolus au lieu de les transformer en confirmation de livraison.
Champs minimaux pour un journal vérifiable
Un journal utile doit permettre de reconstituer ce qui a été reçu, de qui et comment cela a été interprété. Le schéma exact dépend de l’intégration, mais il est conseillé de séparer les données de corrélation, les données d’origine, les heures normalisées et les décisions de réconciliation.
Limitez l’accès aux données permettant l’identification et appliquez les politiques de conservation et de sécurité de votre organisation. La vérifiabilité n’exige pas de traiter des données personnelles au-delà de ce qui est nécessaire pour établir des correspondances et résoudre les incidents.
- Identifiant interne du message et, s’il existe, identifiant attribué par le fournisseur.
- Type d’événement et état tels qu’ils ont été reçus, sans perdre la valeur d’origine.
- Système ou fournisseur d’origine et, si disponible, version ou référence de l’interface.
- Horodatage d’origine, fuseau horaire ou décalage déclaré et précision disponible.
- Horodatage de réception locale et horodatage normalisé, enregistrés séparément.
- Identifiant de l’événement ou du callback, s’il existe, et résultat de la détection des doublons.
- Règle de réconciliation appliquée, résultat, motif et moment de la décision.
- Indicateur d’incertitude lorsque la signification, le fuseau horaire ou la séquence ne peuvent pas être établis.
Exemple : DLR tardif et état final incertain
Supposons qu’une plateforme consigne un envoi, puis reçoive une réponse d’acceptation. Elle consigne ensuite une autre transition et reçoit enfin un callback dont l’horodatage déclaré semble antérieur à l’heure de réception locale. Cet écart peut s’expliquer par un retard de transmission, des conventions d’horodatage différentes, un fuseau horaire inconnu ou des horloges désynchronisées ; sans données supplémentaires, il est impossible de choisir une cause.
La démarche prudente consiste à conserver les deux heures, à associer le callback au message uniquement à l’aide de clés de corrélation appropriées et à signaler la séquence pour examen si elle contredit les règles documentées. Le callback atteste que la plateforme a reçu un rapport contenant certaines informations. En l’absence de documentation précisant sa sémantique et sa portée, il ne faut pas le présenter comme une vérification indépendante de la réception du SMS par le terminal.
- Conservez l’horodatage déclaré du DLR et l’horodatage de réception dans des champs distincts.
- Ne réordonnez pas et ne supprimez pas l’historique pour lui donner une apparence chronologique.
- Consignez l’état communiqué et toute incertitude concernant sa signification.
- Présentez le résultat comme un état communiqué par le fournisseur, et non comme une preuve indépendante de réception par le terminal.
Tests périodiques et limites d’un horodatage
Validez le flux à l’aide de tests contrôlés et légitimes dans vos propres intégrations. Vérifiez que les valeurs d’origine sont conservées, que la conversion des fuseaux horaires est reproductible, que les événements tardifs ne sont pas perdus et que les doublons sont identifiés sans supprimer l’historique. Renouvelez ces vérifications lorsque l’interface, la configuration ou les règles du fournisseur changent.
À lui seul, un horodatage ne prouve pas qui a reçu le message, que l’horloge était synchronisée, que l’événement s’est produit exactement à cette heure ni que le contenu s’est affiché sur le terminal. Les conclusions dépendent de la définition de l’événement, de sa source et des éléments techniques disponibles. Documentez ces limites dans les rapports opérationnels et de réconciliation.
- Testez les horodatages avec et sans fuseau horaire et vérifiez que les valeurs d’origine restent intactes.
- Incluez des cas de callbacks tardifs, répétés et hors séquence.
- Comparez l’interprétation locale à la documentation en vigueur pour chaque intégration.
- Auditez régulièrement les écarts horaires et les résultats de réconciliation, sans les transformer en garanties de livraison.
Questions fréquentes
La réception d’un DLR confirme-t-elle que le SMS est arrivé au terminal ?
La réception du callback confirme que votre système a reçu un rapport. Sa signification dépend de la sémantique documentée par la source et ne constitue pas, à elle seule, une vérification indépendante de la réception par le terminal.
Dois-je enregistrer tous les horodatages en UTC ?
Vous pouvez conserver un champ normalisé en UTC pour comparer les systèmes, mais gardez également la valeur d’origine et le fuseau horaire ou le décalage déclaré. Si le fuseau est inconnu, consignez-le au lieu de le supposer.
Quelle heure doit prévaloir lorsque la plateforme et le fournisseur sont en désaccord ?
Il n’existe pas de règle de priorité universelle applicable à tous les champs. Définissez des règles par type d’événement et selon la documentation de l’intégration, conservez les deux observations et signalez les écarts non résolus.
Comment traiter un callback reçu hors séquence ou en double ?
Conservez-le avec son heure de réception et son horodatage déclaré. Utilisez des identifiants stables pour détecter les doublons lorsqu’ils existent, gardez l’historique et ne supprimez pas les événements au seul motif qu’ils sont arrivés tardivement.
Que démontre l’écart entre deux horodatages ?
Il montre que les journaux contiennent des valeurs différentes ; il n’en identifie pas à lui seul la cause. L’écart peut relever de la sémantique, du fuseau horaire, de la précision, d’un retard ou de l’horloge. Des données supplémentaires sont nécessaires pour en déterminer la cause.
Sources consultées
- 3GPP specifications3GPP
- ITU-T E.164International Telecommunication Union
- GSMA resourcesGSMA