Fallback A2P SMS : quand changer de route et quand interrompre le trafic pour enquêter

Le fallback A2P SMS est une mesure de confinement, pas une garantie de livraison

Le fallback A2P SMS consiste à rediriger de manière contrôlée une partie ou l'ensemble du trafic d'une route primaire vers une route alternative lorsque des signaux de dégradation suffisants sont présents. Son objectif est de réduire l'impact opérationnel pendant que la cause du problème est validée. Il ne transforme pas le SMS en canal avec garantie de livraison et ne supprime pas la nécessité d'enquêter sur la qualité de la route d'origine.

Dans SMPP, la réponse à submit_sm confirme le résultat de cette requête de protocole et renvoie généralement un message_id attribué par le SMSC. Elle ne confirme pas que le message est arrivé sur le terminal. Pour connaître le résultat ultérieur, l'ESME doit demander un SMSC Delivery Receipt ou consulter le statut lorsque cette opération est disponible.

Une politique de fallback mature doit donc décider séparément de deux choses : à quel moment il est raisonnable d'essayer une autre route, et à quel moment le comportement observé impose d'arrêter ou de limiter le trafic afin de préserver les éléments de preuve et d'éviter des dommages supplémentaires.

• Considérez le fallback comme une action réversible et limitée.
• Poursuivez l'investigation même si le trafic alternatif semble fonctionner.
• N'utilisez pas l'acceptation de submit_sm comme preuve de livraison au destinataire.
• N'interprétez pas le rétablissement d'une session SMPP comme le rétablissement complet de la route.

Ce qui peut mal se passer avec un fallback mal conçu

Un changement de route automatique peut protéger une opération critique, mais il peut également amplifier un incident. Le cas le plus délicat survient lorsque le message d'origine a été accepté par le SMSC, reste en cours ou reçoit son état final avec retard, tandis que le système renvoie le même contenu par une seconde route. Le destinataire peut recevoir deux messages, deux codes ou des communications contradictoires.

Il existe aussi un risque de diagnostic. Si le système détourne tout le trafic trop tôt, la dégradation de la route primaire peut être masquée par les résultats agrégés. Sans cohortes de contrôle, journaux corrélables et limites de périmètre, il devient difficile de distinguer une défaillance de connectivité, une validation incorrecte de la destination, une limitation de capacité ou un problème localisé sur une destination ou un opérateur.

Le coût et la traçabilité comptent également. Chaque tentative doit pouvoir être reliée à une seule intention d'envoi et à la route utilisée. Sans cette corrélation, il est impossible de déterminer s'il y a eu nouvelle tentative, doublon, expiration, rejet ou livraison tardive de la première tentative.

• Doublons causés par un renvoi avant de connaître le résultat de la tentative initiale.
• Coût non maîtrisé dû à la multiplication des tentatives ou à l'activation d'un fallback global.
• Perte d'éléments de preuve lorsque les résultats de routes différentes sont mélangés.
• Dégradations persistantes masquées par le détournement du trafic sans isolation de la cause.
• Décisions erronées lorsque toutes les destinations sont regroupées dans un seul indicateur.

Classez le trafic avant de définir les nouvelles tentatives

La même politique ne convient pas à tous les messages légitimes. La sensibilité au temps, au contexte et aux doublons doit faire partie de la décision. Un OTP peut perdre rapidement sa valeur et un second envoi peut perturber l'utilisateur ou invalider un flux d'authentification. Une notification transactionnelle urgente peut justifier une route alternative limitée, à condition que l'application contrôle l'idempotence de l'événement métier. Une campagne marketing fondée sur le consentement permet généralement davantage de prudence : il est préférable d'attendre, de reprogrammer ou d'enquêter plutôt que de dupliquer les communications.

La classification doit exister avant l'incident, et non pendant celui-ci. Chaque intention d'envoi devrait inclure au minimum un type de message, une durée de validité, une politique de nouvelle tentative et une règle explicite indiquant si une seconde route est autorisée ou non.

• OTP : fenêtre d'utilité courte ; évitez les renvois aveugles et contrôlez le cycle de vie du code.
• Transactionnel urgent : appliquez le fallback seulement si l'événement métier permet l'idempotence et si le risque de doublon est défini.
• Notification non critique : privilégiez l'observation, la reprogrammation ou l'envoi différé plutôt qu'une nouvelle tentative immédiate.
• Marketing fondé sur le consentement : n'utilisez pas l'urgence comme justification pour multiplier les messages ; respectez la politique de contact applicable.

Signaux pouvant justifier un changement de route

Les signaux doivent être évalués par couches. Les erreurs de protocole immédiates peuvent exiger une réaction différente des résultats finaux de livraison. SMPP définit command_status pour communiquer le succès ou l'échec d'une requête. Parmi les erreurs possibles figurent les erreurs système, les limites de messages dépassées et les validations d'adressage. Une erreur de TON ou de NPI de destination n'est pas, à elle seule, une preuve de dégradation de la route : elle peut indiquer un problème de normalisation ou de configuration de l'envoi.

La disponibilité de session doit également être dissociée de la performance de livraison. Un bind peut être actif et la route peut néanmoins rencontrer des problèmes lors de submit_sm, de la réception des DLR ou du traitement ultérieur du message. De même, le rétablissement d'une session ne démontre pas que les résultats finaux sont revenus à des niveaux opérationnels acceptables.

L'absence de DLR ne peut être un signal pertinent que si elle est interprétée au regard de la configuration des receipts, de la fenêtre d'observation, du type de message et du comportement historique connu de cette intégration. Les notifications intermédiaires ne constituent pas une base portable pour un fallback global : leur prise en charge dépend de l'implémentation du SMSC.

• Erreurs de protocole répétées affectant submit_sm ou les commandes nécessaires à l'exploitation.
• Throttling ou limites de capacité imposant de réduire le débit avant d'augmenter le nombre de routes.
• Erreurs d'adresse, de TON ou de NPI à isoler comme problème potentiel de validation.
• Perte ou instabilité de session, à distinguer des résultats d'envoi et de livraison.
• Dégradation observée des états finaux ou de la latence, segmentée par destination et par route.
• Absence anormale de DLR, après avoir vérifié qu'ils ont été demandés et que l'intégration les traite correctement.

Ne confondez pas les états SMPP avec une réception indépendante sur le terminal

La nomenclature des états doit être gérée avec précision. ENROUTE signifie que le message est en cours d'acheminement ; ce n'est pas une livraison. DELIVERED est un état distinct dans SMPP. ACCEPTED ne doit pas non plus être interprété comme une réception sur le terminal : la spécification le décrit comme un message accepté après avoir été lu manuellement au nom de l'abonné par le service client.

Un DLR est précieux pour l'exploitation et la corrélation d'événements, mais il ne doit pas être traité comme une preuve indépendante et uniforme chez tous les fournisseurs. SMPP permet d'insérer les informations d'un delivery receipt dans short_message selon un format propre au fournisseur du SMSC. Les codes d'erreur peuvent également dépendre du réseau ou du SMSC. La normalisation interne doit toujours préserver la valeur d'origine avec une classification opérationnelle documentée.

La conclusion pratique est simple : n'activez pas un renvoi uniquement parce qu'un message est toujours ENROUTE, parce que le DLR n'est pas arrivé dans une fenêtre arbitraire ou parce qu'un fournisseur utilise une étiquette textuelle qui semble définitive. Utilisez des règles fondées sur le contexte, la durée de validité, le schéma de l'incident et le risque de doublon.

• submit_sm_resp : confirme la réponse au submit, et non la livraison finale.
• ENROUTE : état en cours ; ne déclenchez pas de renvoi sur la seule base de cet état.
• DELIVERED : état de livraison signalé par l'écosystème SMS, et non vérification indépendante d'une lecture humaine.
• ACCEPTED : n'équivaut pas à une réception sur le terminal.
• EXPIRED, UNDELIVERABLE, REJECTED et UNKNOWN : doivent être conservés comme résultats distincts pour l'analyse et la décision.

Concevez des seuils segmentés, pas un interrupteur global unique

Un seuil global mélange des populations dont les comportements peuvent être différents. La politique doit segmenter, au minimum, par destination normalisée conformément au plan de numérotation applicable. Dans l'échange SMPP, destination_addr, TON et NPI font partie du contexte technique qu'il convient d'enregistrer et de valider. Lorsque la télémétrie disponible le permet, ajoutez la route, le type de message, l'expéditeur, la plage horaire et la classe d'erreur.

Les seuils doivent combiner un volume minimal et une fenêtre temporelle. Une faible variation avec peu d'observations ne devrait pas entraîner un changement massif. De même, une dégradation concentrée sur une destination ne doit pas justifier le détournement de pays ou de destinations non affectés. Définissez à l'avance quelle combinaison de signaux déclenche l'observation, le fallback limité, le confinement ou l'investigation.

Il n'est pas prudent de fixer des valeurs universelles de pourcentage, de minutes ou de nombre de nouvelles tentatives sans connaître le comportement contractuel, technique et opérationnel de chaque intégration. Le bon seuil est celui qui peut être expliqué, testé et révisé avec les données disponibles.

• Exigez un nombre minimal d'observations avant d'évaluer une dégradation agrégée.
• Mesurez dans des fenêtres temporelles définies et conservez l'heure de chaque événement.
• Segmentez par destination, route, type de message et, lorsque cela est pertinent, expéditeur et classe d'erreur.
• Distinguez les erreurs de validation de destination des indicateurs de qualité de route.
• Documentez la raison précise déclenchant chaque transition d'état.

Définissez une machine à états opérationnelle

Une politique de fallback doit pouvoir être exprimée sous la forme d'une machine à états qu'un opérateur peut auditer. Cela réduit les décisions ambiguës et empêche une automatisation de passer directement d'une alerte isolée à un détournement massif. La machine à états ne remplace pas les états SMPP ; elle organise la réponse opérationnelle face aux signaux de protocole, de disponibilité et aux résultats observés.

Un modèle pratique part de la route primaire dans des conditions normales, passe à l'observation en présence de signaux initiaux, utilise un fallback limité lorsque les éléments de preuve sont suffisants et maintient une phase explicite de confinement et d'investigation pour les incidents persistants. Le rétablissement exige une validation progressive, et non le seul retour de la connectivité.

• Route primaire : trafic normal et surveillance segmentée.
• Observation : alerte ouverte, validation des données, sans détournement ou avec un périmètre de test minimal.
• Fallback limité : détournement d'une cohorte définie, avec un budget de tentatives et des contrôles des doublons.
• Confinement : réduction, pause ou isolation du trafic affecté lorsque le risque dépasse le bénéfice du renvoi.
• Investigation : analyse des corrélations, de la configuration, des erreurs et des changements récents.
• Rétablissement : retour progressif vers la route primaire après des critères vérifiables de stabilité.

Contrôles contre les doublons et les nouvelles tentatives sans contexte

Le principal contrôle contre les doublons consiste à séparer l'intention métier de la tentative technique. Attribuez un identifiant interne stable à chaque intention d'envoi et reliez chaque tentative à la route, au moment, au contenu applicable et au message_id renvoyé par chaque SMSC. SMPP prévoit également user_message_reference comme référence attribuée par l'ESME, mais la déduplication entre routes doit être résolue dans la logique de l'application, et non supposée à partir d'un seul champ de protocole.

Avant d'engager un fallback, vérifiez si la première tentative a un résultat final connu, si elle reste dans sa période de validité et si un second envoi aurait du sens pour l'utilisateur. La fenêtre d'attente doit être liée à la validité du message. SMPP permet d'indiquer validity_period et prévoit que le SMSC rejette le message à son expiration s'il n'a pas été livré.

La fonction replace_if_present_flag ne résout pas la déduplication universelle. Elle demande seulement le remplacement d'un message en attente et dépend de la correspondance entre source address, destination address et service_type. Il ne faut pas supposer qu'elle fonctionnera entre différents fournisseurs, SMSC ou routes.

• Utilisez un ID interne par intention d'envoi et un ID par tentative technique.
• Conservez le message_id de chaque SMSC sans le remplacer par un identifiant générique.
• Appliquez l'idempotence à l'événement métier, et pas uniquement au transport SMS.
• Définissez une fenêtre d'attente avant d'envisager une seconde tentative.
• Ne renvoyez pas automatiquement les messages dont le contenu peut être invalide, contradictoire ou sensible au contexte.
• Ne considérez pas replace_if_present_flag comme un mécanisme de déduplication entre routes.