Événements A2P SMS dupliqués et désordonnés : comment les réconcilier sans perdre les preuves

Pourquoi les événements peuvent-ils être dupliqués, retardés ou désordonnés ?

Dans une intégration A2P, un envoi peut générer des observations à plusieurs étapes : la requête API, une réponse d’acceptation ou de rejet, une interaction SMPP et, si disponible, un rapport de livraison (DLR). Ces signaux n’arrivent pas nécessairement ensemble ni dans l’ordre où les faits se sont produits. Des notifications peuvent également être réessayées ou répétées.

La sémantique exacte dépend de l’interface et du fournisseur. Il n’existe pas de règle de priorité universelle permettant de conclure, pour tous les systèmes, qu’un événement API prévaut sur un événement SMPP ou que tout DLR a la même signification. Documentez ce que représente chaque événement dans votre intégration avant de l’utiliser pour mettre à jour un état.

• Distinguez le moment où le système affirme qu’un événement s’est produit du moment où votre plateforme l’a reçu.
• Considérez les messages répétés comme une éventualité opérationnelle, et non comme la preuve que le fait sous-jacent s’est produit plusieurs fois.
• Ne supposez pas qu’un événement manquant équivaut à un échec, à une livraison ou à une annulation.

Séparez le registre d’origine de la vue d’état calculée

Distinguez deux notions. Le registre d’événements conserve les éléments reçus ; la projection opérationnelle résume ce que la plateforme peut affirmer à ce moment-là. Si une règle de réconciliation change, la projection peut être recalculée à partir du registre, sans supprimer ni réécrire les éléments qui ont produit le résultat.

Pour chaque événement, conservez, lorsqu’ils sont disponibles, le contenu reçu, la source ou l’interface, l’identifiant de corrélation, les horodatages déclarés et observés, ainsi que le résultat des validations. Évitez de remplacer un événement antérieur par un événement ultérieur au seul motif que ce dernier semble plus concluant.

Les exigences de conservation, de protection contre les altérations et d’audit doivent être adaptées aux obligations de votre organisation et aux contrats applicables. Aucune garantie universelle de stockage immuable n’est formulée ici.

• Enregistrez l’observation d’origine et consignez séparément toute normalisation.
• Versionnez les règles utilisées pour calculer la projection.
• Permettez de reconstruire les événements et les règles qui ont produit l’état affiché.

Définissez l’identité et la déduplication sans supposer l’existence d’une clé globale

Ne présumez pas qu’il existe un identifiant unique partagé entre l’API, SMPP, les agrégateurs et les opérateurs. Un identifiant peut n’être valable qu’au sein d’un compte, d’une connexion, d’un fournisseur ou d’une période. Définissez la portée de chaque identifiant en fonction de la documentation de l’interface concernée.

En l’absence de clé fiable, ne regroupez pas des événements simplement parce que le destinataire, le texte et une heure approximative coïncident : deux messages légitimes peuvent partager ces attributs. Dans ce cas, conservez les deux et marquez-les comme doublons possibles ou comme corrélation incertaine, au lieu d’écarter des éléments de preuve.

La normalisation du numéro peut faciliter les recherches, mais ne prouve pas à elle seule que deux enregistrements correspondent au même envoi. E.164 est une recommandation de numérotation ; elle ne fournit pas en soi une règle de corrélation des messages.

• Utilisez d’abord l’identifiant documenté par l’interface et sa portée : compte, connexion ou fournisseur.
• Consignez les règles de déduplication et le motif de chaque correspondance.
• Si la corrélation est ambiguë, conservez l’événement et évitez de fusionner automatiquement les messages.

Triez avec prudence : temps déclaré, temps observé et séquence

Conservez séparément l’horodatage fourni par l’émetteur de l’événement et l’heure à laquelle votre système l’a observé. L’heure déclarée peut décrire le moment d’origine ; l’heure observée indique quand l’événement est arrivé sur votre plateforme. Aucun de ces temps ne doit remplacer silencieusement l’autre.

Si l’interface fournit une séquence ou une version dont la sémantique est documentée, évaluez la possibilité de l’utiliser dans la portée où elle est valable. En l’absence de signal d’ordre fiable, ne transformez pas l’ordre d’arrivée en chronologie définitive. Une règle stable de départage peut rendre le calcul reproductible, mais ne prouve pas ce qui s’est produit en premier.

Consignez le fuseau horaire, la précision et les éventuels problèmes d’horloge lorsque ces données sont disponibles. Si elles manquent, tenez compte de cette limite dans l’évaluation de l’événement.

• Enregistrez au minimum le temps déclaré et l’heure de réception dans des champs distincts.
• N’utilisez les séquences que si leur portée et leur signification sont connues.
• Signalez l’ordre relatif comme incertain lorsque les éléments disponibles ne permettent pas de le déterminer.

Définissez des transitions explicites et ne déduisez pas une livraison

Concevez une machine à états pour votre système à partir des significations documentées pour chaque interface. Il n’existe pas de priorité universelle entre acceptation, erreur, état intermédiaire et DLR qui puisse s’appliquer sans connaître le fournisseur et le contrat technique.

Une acceptation d’envoi indique uniquement ce que l’interface documente au sujet de la requête. Un DLR doit être interprété selon sa source et sa sémantique ; sa réception n’équivaut pas automatiquement à une vérification indépendante confirmant que la personne a vu le SMS ou que le message est arrivé sur l’appareil dans tous les cas.

Lorsque les éléments disponibles ne suffisent pas pour trancher, affichez un état tel que « en attente », « inconnu » ou « en conflit », selon votre modèle. Le libellé doit indiquer clairement qu’il ne s’agit pas d’une livraison confirmée.

• Documentez les événements qui autorisent chaque transition et leur signification dans cette intégration.
• Définissez les conditions dans lesquelles un état incertain est conservé et une contradiction signalée.
• Ne transformez pas l’absence de DLR, une acceptation ou un code non interprété en livraison confirmée.

Gérez les contradictions et les DLR tardifs sans perdre l’historique

Si un DLR arrive après que l’interface a signalé un échec, ou si deux sources semblent se contredire, conservez les deux événements et évaluez leur signification selon la documentation applicable. Ne supprimez pas l’événement antérieur et ne choisissez pas automatiquement le plus récent : l’heure de réception ne détermine pas à elle seule lequel fait autorité.

La projection peut être mise à jour lorsqu’une nouvelle observation apporte des éléments pertinents, mais il faut consigner ce qui a changé, le moment du recalcul et la règle appliquée. Si le conflit ne peut pas être résolu, il est plus exact de le laisser visible que de le masquer derrière un état unique présenté comme définitif.

• Enregistrez les contradictions comme une condition explicite, et non comme un écrasement silencieux.
• Définissez quand une règle permet de résoudre un conflit et quand une vérification est nécessaire.
• Conservez les événements tardifs à des fins d’audit et de retraitement.

Rendez la réconciliation reproductible et auditable

Un retraitement devrait produire le même résultat lorsqu’il est exécuté avec le même ensemble d’événements, les mêmes règles et la même version de configuration. Pour vous en rapprocher, séparez l’ingestion de la projection et évitez que le résultat dépende d’effets secondaires non consignés.

L’idempotence peut s’appliquer au traitement d’une notification lorsqu’une identité fiable et une portée définie existent. En leur absence, une déduplication trop agressive risque d’écarter des éléments valides. Il est préférable de consigner le critère utilisé, de conserver l’observation reçue et de signaler les correspondances incertaines.

Surveillez les tendances anormales, telles qu’une hausse des événements répétés, un délai inhabituel entre les types d’événements ou des contradictions récurrentes. Les alertes doivent décrire ce qui a été observé ; n’en attribuez pas la cause sans éléments probants.

• Versionnez les règles de projection et consignez la version appliquée.
• Permettez de recalculer les états à partir de l’historique conservé.
• Mesurez les doublons, les retards et les conflits par interface et par portée, sans en faire des garanties de qualité.

Exemple : acceptation, échec temporaire et DLR tardif

Supposons que l’API réponde par une acceptation de la requête. Plus tard, un signal que votre intégration interprète comme un échec temporaire arrive, puis un DLR apparaît. Les noms et les significations exacts doivent provenir de la documentation de ce fournisseur ; cet exemple ne définit pas une séquence normative.

Commencez par conserver les trois événements avec leurs temps déclarés et leurs heures de réception, leurs identifiants et leur portée connue. Vérifiez s’ils peuvent être corrélés de manière fiable. Appliquez ensuite les règles documentées : l’acceptation ne prouve pas la livraison, l’échec temporaire ne doit pas être effacé par l’arrivée d’un événement ultérieur, et le DLR ne permet de tirer une conclusion que dans les limites de sa sémantique.

Si la documentation établit que ce DLR représente un résultat de livraison pour le message corrélé, la projection peut refléter ce résultat en précisant clairement sa portée. Si sa sémantique, son identité ou son lien avec l’envoi ne sont pas confirmés, conservez un état incertain ou en conflit. En aucun cas cet exemple ne permet d’affirmer que l’utilisateur a vu le SMS ou qu’une réception indépendante sur le téléphone a été constatée.

• Conclure : une acceptation, un signal d’échec et un DLR ont été reçus ; leur corrélation et leur signification doivent être vérifiées.
• Ne pas conclure sans documentation : l’acceptation ne confirme pas la livraison et le DLR ne prouve pas que l’utilisateur a effectivement reçu le message.
• Laisser en suspens : tout conflit d’identité, d’ordre ou de sémantique que les éléments disponibles ne permettent pas de résoudre.