Taxonomie des échecs A2P SMS : comment classer les rejets, expirations et résultats incertains

Pourquoi un statut unique d’échec ne suffit pas pour exploiter une route

Un statut unique d’« échec » simplifie le reporting, mais supprime les informations nécessaires pour décider de la suite. Une requête SMPP rejetée en raison d’une adresse de destination invalide n’équivaut pas à un SMS accepté par le SMSC puis expiré pendant sa période de validité, ni à l’absence de DLR interprétable reçue par le système.

La taxonomie des échecs A2P SMS doit permettre de comparer les résultats entre routes, fournisseurs, destinations et périodes, sans remplacer la preuve technique d’origine. Son objectif n’est pas de deviner la cause finale de chaque message, mais d’organiser les faits observables et d’associer à chaque cas une action proportionnée.

Une classification utile répond à quatre questions : où le résultat s’est-il produit, est-il final ou peut-il évoluer, quelle preuve l’étaye et quelle action est autorisée ? Cette discipline réduit les nouvelles tentatives inutiles, évite les attributions erronées et améliore la qualité des escalades techniques.

• N’utilisez pas « échec » comme cause racine.
• Distinguez le résultat de la requête, le statut de livraison et la cause confirmée.
• Différenciez les statuts finaux des statuts intermédiaires.
• Conservez toujours le code et le texte d’origine reçus, même après l’application d’un mappage interne.

Principe de preuve : faits observables, inférences et causes confirmées

La première règle consiste à séparer le fait technique de son interprétation. Une réponse SMPP avec un command_status de succès atteste que l’opération de protocole a été acceptée ; elle ne confirme pas que le SMS est arrivé sur le terminal. De même, un DLR portant le statut DELIVERED est une confirmation reçue via la chaîne de livraison, et non une vérification indépendante et universelle de la lecture ou de la réception physique par une personne.

Les DLR peuvent inclure un identifiant, une date d’envoi, une date de clôture, un statut et un code d’erreur. Ces champs permettent de reconstituer un cycle de vie, à condition que l’identifiant puisse être associé de manière fiable au message d’origine. Toutefois, le format précis des receipts transportés dans short_message peut varier selon la passerelle ou le SMSC ; le parseur doit donc être contrôlé par fournisseur ou par route.

L’absence de DLR ne prouve pas non plus à elle seule une non-livraison. Elle peut s’expliquer par l’absence de réception du callback, l’impossibilité d’interpréter le DLR, un décalage de réconciliation ou une politique de reporting de la chaîne amont. Elle doit être classée comme une incertitude jusqu’à l’obtention d’éléments supplémentaires.

• Fait observable : réponse HTTP, submit_sm_resp, DLR, callback, consultation de statut ou timeout interne.
• Inférence : « congestion probable », « restriction possible de l’expéditeur » ou « filtrage possible ».
• Cause confirmée : uniquement lorsqu’un code, une réponse documentée ou une investigation du fournisseur l’identifie.
• Niveau de confiance : indiquez si la classification est directe, déduite ou en attente de confirmation.

Les cinq familles opérationnelles de résultats

Une taxonomie minimale et comparable peut organiser les issues en cinq familles. Chaque famille doit conserver le statut d’origine, la source de la preuve et le niveau de confiance. Les familles ne remplacent pas les codes du fournisseur : elles les regroupent à des fins d’exploitation, d’analyse et de décision.

Une même route peut produire des résultats appartenant à plusieurs familles. Il n’est donc pas pertinent d’évaluer une route à partir d’un seul pourcentage agrégé sans examiner la composition des échecs, leur évolution dans le temps et les preuves disponibles.

• Rejet avant acceptation : la plateforme locale interrompt la tentative avant d’atteindre le SMSC, ou le SMSC rejette la requête. Distinguez ces deux situations. Exemples techniques possibles : échec de bind, identifiants invalides, adresse d’origine invalide ou adresse de destination invalide.
• Échec temporaire : la preuve du fournisseur l’identifie explicitement comme temporaire ou réessayable. Ne transformez pas une erreur générique en erreur temporaire par commodité opérationnelle.
• Échec final : il existe un résultat négatif final pour lequel la documentation ou les preuves disponibles n’indiquent pas de nouvelle tentative sûre. Un rejet du SMSC peut appartenir à cette famille lorsqu’il est susceptible de se reproduire avec la même requête.
• Expiration : le message a épuisé sa fenêtre de validité avant que la livraison ne soit finalisée. Cette catégorie doit être distinguée de l’échec final, car la durée de validité et le cas d’usage sont importants.
• Résultat incertain : le SMSC a pu accepter le message, mais aucun DLR reçu et interprétable ne permet de le clôturer comme livré, en échec ou expiré.

Données à conserver pour chaque message

La classification sera fragile si les enregistrements ne permettent pas de reconstituer la séquence. L’identifiant interne doit coexister avec les identifiants attribués par la plateforme, le fournisseur ou le SMSC. Le DLR doit être lié au message d’origine sans dépendre uniquement d’un texte de receipt susceptible de varier selon les implémentations.

La destination doit être stockée dans un format international normalisé conforme à la structure du plan E.164, séparément des attributs utilisés pour le routage ou la segmentation. La normalisation ne rend pas un numéro valide, actif, consentant ou livrable ; elle améliore seulement la cohérence du traitement des données et de l’analyse.

Il est également important de conserver une classification contrôlée du contenu et de l’expéditeur, sans utiliser ces champs pour déduire une cause en l’absence de preuve. Par exemple, une différence de comportement selon le type d’expéditeur peut justifier une investigation, mais ne confirme pas à elle seule une restriction de l’expéditeur.

• Identifiant interne de la tentative et du message logique.
• Identifiants de la plateforme, du fournisseur, du SMSC et du DLR lorsqu’ils existent.
• Horodatages : création, acceptation, envoi, mise à jour, réception du DLR et clôture interne.
• Destination normalisée, pays associé et opérateur uniquement lorsque la donnée existe avec une preuve suffisante.
• Expéditeur, type d’expéditeur et configuration pertinente de la requête.
• Route, fournisseur, connexion, version du parseur et version du mappage.
• Classe de contenu ou cas d’usage : OTP, transactionnel ou marketing légitime.
• Statut et code d’origine, texte d’origine, famille normalisée, niveau de confiance et action suivante.

Comment mapper HTTP, SMPP et DLR sans perdre d’informations

Le mappage doit constituer une couche supplémentaire et réversible. Enregistrez d’abord la réponse d’origine, puis appliquez une règle versionnée qui produit une catégorie opérationnelle. N’écrasez pas un code SMPP, un statut HTTP ou le texte d’un DLR par une étiquette interne telle que « numéro invalide » ou « filtré » si cette cause n’est pas confirmée.

En SMPP, command_status indique le succès ou l’échec d’une requête SMPP. Des codes tels que ESME_RINVSRCADR, ESME_RINVDSTADR, ESME_RSYSERR, ESME_RBINDFAIL et ESME_RINVPASWD ont des significations techniques distinctes et doivent rester disponibles pour le diagnostic. Une réponse positive à submit_sm ne doit pas être mappée sur « livré » : elle doit être mappée, au plus, sur « accepté par l’opération de protocole » ou sur un statut intermédiaire équivalent.

Les statuts de livraison nécessitent également une hiérarchie temporelle. ENROUTE est intermédiaire et peut évoluer, par exemple, vers DELIVERED ou EXPIRED. Un parseur ne doit pas clôturer un message de manière irréversible tant qu’il ne dispose que d’un statut susceptible de changer.

• Capturez : protocole, endpoint ou commande, code, texte, payload d’origine et horodatage de réception.
• Appliquez une règle avec une version, un périmètre et une date d’entrée en vigueur.
• Définissez la priorité entre les mises à jour : un DLR final valide doit prévaloir sur un statut intermédiaire antérieur.
• Conservez les DLR non interprétables dans une file de révision et classez-les temporairement comme résultat incertain.
• Versionnez les parseurs par fournisseur, connexion ou route lorsque le format du receipt l’exige.
• Évitez de dépendre par programmation de textes changeants d’erreurs spécifiques ; utilisez-les comme preuves diagnostiques conservées.

Classification selon l’actionnabilité

L’utilité d’une taxonomie se démontre lorsqu’elle guide des actions sûres. Toutes les catégories n’autorisent pas une nouvelle tentative et tout incident n’exige pas l’arrêt du trafic. L’action doit dépendre de la famille, du code d’origine, du cas d’usage, de la fenêtre de validité et des preuves accumulées.

Les décisions doivent être appliquées selon des règles explicites. Une nouvelle tentative peut être appropriée lorsque le fournisseur identifie le résultat comme temporaire ou réessayable ; elle ne doit pas être appliquée automatiquement à des rejets susceptibles de produire la même erreur avec la même requête. En cas d’incertitude, réconciliez d’abord le statut avant de créer des doublons.

• Corriger les données ou la configuration : appliquez cette action à des preuves telles qu’une destination invalide, un expéditeur invalide, une erreur de bind ou des identifiants incorrects. Validez avant de renvoyer.
• Réessayer en toute sécurité : uniquement avec une preuve de temporalité ou de possibilité de nouvelle tentative, une politique de déduplication et une fenêtre de validité encore utile.
• Arrêter ou limiter le trafic : en cas d’augmentation persistante des rejets techniques, des échecs d’authentification, des erreurs système ou de changements de comportement affectant une route. La mesure doit être réexaminée à partir des données, et non d’une attribution automatique.
• Escalader auprès du fournisseur : en cas de codes persistants, de DLR incohérents, de receipts non interprétables, de divergences d’identifiants ou d’augmentation des résultats incertains.
• Maintenir sous observation et réconcilier : pour les statuts intermédiaires, l’absence de DLR dans la fenêtre définie ou les conflits entre sources de statut.

Erreurs ambiguës : quand utiliser « cause non déterminée »

Une catégorie « cause non déterminée » est nécessaire lorsque les preuves ne permettent pas d’identifier une cause précise. Il ne s’agit pas d’un échec d’analyse : c’est un moyen d’empêcher qu’une hypothèse devienne une donnée opérationnelle. Elle doit être utilisée, par exemple, lorsqu’un statut générique de non-livraison est reçu sans code permettant de distinguer les causes possibles.

N’attribuez pas automatiquement une non-livraison au filtrage de contenu, à l’indisponibilité du terminal, à une restriction de l’expéditeur, à la congestion ou à un problème de numérotation. Un statut négatif peut couvrir plusieurs causes. L’attribution doit attendre un code spécifique, une réponse documentée du fournisseur, une preuve cohérente par segment ou une investigation confirmée.

Pour être utile, cette catégorie ne doit pas devenir un fourre-tout permanent. Chaque cas doit conserver suffisamment de métadonnées afin de pouvoir être reclassé si un DLR tardif arrive, si le parseur est mis à jour ou si le fournisseur apporte une clarification.

• Utilisez « cause non déterminée » lorsqu’il manque une preuve discriminante.
• N’utilisez pas cette catégorie pour masquer des erreurs de parseur, des pertes de callbacks ou un manque de corrélation : enregistrez ces problèmes séparément.
• Mesurez sa proportion par route, fournisseur, destination et version d’intégration.
• Ouvrez une révision si elle augmente de façon persistante ou si elle se concentre sur une même route ou un même format de DLR.
• Ne reclassifiez qu’au moyen d’une règle versionnée et conservez l’historique du changement.

Des règles différentes pour les OTP, les messages transactionnels et le marketing légitime

La catégorie d’échec ne change pas selon le cas d’usage, mais l’action peut changer. Un OTP a une utilité limitée dans le temps et exige une attention particulière aux nouvelles tentatives : envoyer un code dupliqué ou tardif peut dérouter le destinataire et ne pas résoudre l’accès. Le système doit respecter la validité du code et éviter les nouvelles tentatives lorsqu’elles n’apportent plus de valeur.

Les messages transactionnels peuvent tolérer une politique de nouvelle tentative différente si leur contenu reste valide et si l’événement n’est pas dupliqué de manière préjudiciable. Le marketing légitime exige une discipline encore plus rigoureuse : il ne doit être envoyé qu’à des destinataires disposant de la base légale et des autorisations applicables, et un résultat incertain ne doit pas servir à justifier des renvois répétés.

La période de validité fait partie de la décision. L’expiration indique que le message est resté en attente jusqu’à épuiser une fenêtre configurée avant d’échouer sur la plateforme. Analysez donc les expirations en tenant compte de la validité configurée, et pas seulement comme un indicateur de qualité de route.

• OTP : clôture rapide, déduplication stricte et nouvelle tentative uniquement si elle reste dans la validité du code et si la politique l’autorise.
• Transactionnel : validez l’idempotence, la validité de l’événement et le risque de duplication avant toute nouvelle tentative.
• Marketing légitime : limitez la fréquence, respectez le consentement et les exclusions applicables, et n’utilisez pas l’incertitude comme motif pour insister.
• Pour tous les cas : documentez la politique de nouvelles tentatives, le nombre maximal de tentatives et la condition de clôture.