La disponibilité n’est pas la délivrabilité : mesurer les trois couches de santé d’une route A2P SMS

Une route disponible n’est pas toujours opérationnellement saine

Dans les opérations A2P SMS, qualifier une route de « disponible » peut masquer trois questions différentes. La connexion technique fonctionne-t-elle ? Le système accepte-t-il les messages envoyés ? Les messages produisent-ils un résultat de livraison interprétable et réconciliable ? Une réponse positive à la première question ne répond pas automatiquement aux deux autres.

Une session SMPP peut être établie, répondre à ses vérifications de liaison et rester ouverte alors qu’une route présente des rejets d’envoi, une accumulation de requêtes en attente, une dégradation de la latence ou une baisse des DLR. De même, un submit accepté peut signifier que le SMSC a accepté le message via la connexion SMPP, et non que le destinataire l’a reçu.

La disponibilité et la délivrabilité des routes A2P SMS doivent donc être évaluées comme un ensemble de signaux liés, mais non équivalents. Les séparer évite qu’une métrique favorable ou défavorable domine une décision qui exige du contexte.

• N’utilisez pas une session active comme substitut à la livraison.
• Ne comptabilisez pas les requêtes acceptées, mises en file d’attente ou envoyées comme des messages livrés.
• N’interprétez pas l’absence de DLR comme une preuve automatique de non-livraison sans examiner le comportement convenu de la route et le processus de réconciliation.
• Comparez les résultats entre des populations homogènes ; ne mélangez pas les tests synthétiques et le trafic de production dans un même pourcentage.

Les trois couches de mesure

Le modèle opérationnel le plus utile sépare la santé d’une route en trois couches. La première concerne la disponibilité technique entre les systèmes qui échangent le trafic. La deuxième concerne l’acceptation de chaque requête d’envoi. La troisième concerne le résultat de livraison ultérieur communiqué par les mécanismes disponibles.

Chaque couche nécessite ses propres identifiants, fenêtres temporelles, métriques et seuils internes. Elle exige également une conclusion formulée avec précision : « connectivité confirmée », « submit accepté » ou « DLR final reçu » décrivent des faits distincts et ne doivent pas être substitués les uns aux autres.

• Couche 1 : disponibilité technique. Mesure la session, la connectivité, les réponses et les temps de réponse.
• Couche 2 : acceptation du trafic. Mesure les réponses aux envois, les rejets synchrones, les requêtes en attente, les files d’attente et les timeouts.
• Couche 3 : résultat de livraison. Mesure les DLR, les statuts finaux, les statuts intermédiaires lorsqu’ils existent et la latence jusqu’au résultat.

Couche 1 : la disponibilité technique ne prouve pas la livraison

En SMPP, enquire_link et enquire_link_resp servent à vérifier la fiabilité du canal de communication et le fonctionnement de la connexion applicative entre l’ESME et le SMSC. Ce sont des signaux appropriés pour vérifier si la session répond, détecter des pertes de connectivité et mesurer le temps de réponse de cet échange.

Ces signaux ne prouvent pas qu’un message a été acheminé vers un réseau mobile, que la destination est joignable ou que l’abonné a reçu un SMS. Le modèle SMPP prévoit lui-même des mécanismes distincts pour demander et transporter les accusés de réception de livraison.

La mesure de la connectivité doit enregistrer le cycle de vie de la session et les événements de maintenance, sans extrapoler ces résultats à la couche de livraison.

• Heure d’établissement et de fermeture de session.
• Résultat du bind et erreurs de session.
• Envois d’enquire_link, réponses reçues, pertes et temps de réponse.
• Reconnexions, durée des interruptions et fréquence des timeouts.
• Événements séparés par compte, lien, route déclarée le cas échéant et fenêtre temporelle.

Couche 2 : ce que démontre l’acceptation du trafic

L’acceptation répond à une question plus limitée que la livraison : l’extrémité réceptrice a-t-elle accepté cette requête à cet instant ? Dans le flux SMPP, une réponse satisfaisante à une requête d’envoi peut attester de l’acceptation du message par le SMSC via la connexion. Le résultat final exige un suivi ultérieur, généralement au moyen d’un Delivery Receipt demandé pour le message.

Dans les plateformes de messagerie fondées sur des API, une distinction équivalente s’applique : une requête peut être acceptée ou mise en file d’attente avant que le message ne soit envoyé à un opérateur en amont et avant qu’une confirmation ou un accusé de non-livraison n’existe. Traitez chaque transition comme une étape, et non comme une garantie rétrospective.

La capacité ne doit pas non plus être déduite uniquement d’un bind ouvert. SMPP ne fixe pas de maximum universel d’opérations en attente ; celui-ci dépend de l’implémentation du SMSC. Une route apparemment disponible peut donc se dégrader lorsque les requêtes simultanées augmentent.

• Enregistrez les codes de réponse de submit et les rejets synchrones.
• Mesurez les timeouts de réponse ainsi que les requêtes en attente ou non confirmées.
• Observez l’évolution des files d’attente et des échecs d’envoi lorsque l’interface expose ces statuts.
• Associez chaque envoi à son identifiant de message, sa destination normalisée, son expéditeur, son contenu ou sa classe de contenu, sa route et son horodatage.
• Évaluez l’acceptation sous une charge autorisée et contrôlée ; un test isolé ne caractérise pas une capacité soutenue.

Couche 3 : DLR et limites des preuves de livraison

Un SMSC Delivery Receipt est un signal généré par le SMSC lorsqu’il détecte l’état final d’un message enregistré. En SMPP, il peut être reçu via deliver_sm ou data_sm et contient des champs utiles à la corrélation et à l’interprétation, tels que l’identifiant du message reçu, message_state et, lorsqu’il est présent, network_error_code.

Un DLR final est une preuve plus proche du résultat de livraison qu’une réponse de submit, mais il reste un signal de l’écosystème de messagerie, et non une preuve universelle et indépendante de lecture, d’interaction ou de réception vérifiée sur le terminal. La sémantique précise et la portée des confirmations dépendent du réseau, du fournisseur et de l’implémentation.

Les statuts intermédiaires doivent être traités séparément. Ils peuvent, par exemple, signaler une première tentative échouée alors que le message reste conservé pour de nouvelles tentatives. Leur prise en charge dépend de l’implémentation du SMSC et du fournisseur ; ne supposez pas que toutes les routes les émettront et ne considérez pas leur absence comme nécessairement défaillante.

• Conservez l’identifiant d’envoi et l’identifiant référencé dans le DLR afin de réconcilier les événements.
• Séparez les DLR finaux des notifications intermédiaires.
• Mesurez le temps entre l’acceptation et le DLR, ainsi que la proportion de DLR reçus dans une fenêtre définie en interne.
• Classez les statuts selon la documentation contractuelle et technique de chaque intégration ; ne forcez pas d’équivalences entre des vocabulaires différents.
• Décrivez « DLR de livraison reçu » sans le transformer en « lecture confirmée » ou « réception indépendante sur le terminal ».

Concevoir des tests synthétiques légitimes et contrôlés

Les tests synthétiques aident à détecter des changements de comportement avant qu’ils n’affectent largement le trafic, mais ils doivent être réalisés uniquement vers des destinations autorisées et avec des contrôles de conformité. Leur valeur provient du maintien de variables connues, non d’une tentative de reproduire toute la diversité du trafic commercial.

Utilisez des destinations de test sous votre contrôle ou faisant l’objet d’une autorisation explicite. Normalisez les numéros au format E.164 afin de réduire les ambiguïtés de format et de maintenir une segmentation cohérente par pays ou destination internationale. Tenez un inventaire des destinations, de l’autorisation applicable, de la route prévue, de l’expéditeur et du profil de contenu utilisé.

Concevez des cas permettant de comparer un même signal dans le temps. Si vous modifiez simultanément la destination, l’expéditeur, le texte et la route, il sera difficile d’attribuer la cause d’une variation.

• Définissez un ensemble autorisé de destinations de test et révisez-le périodiquement.
• Testez séparément la connectivité, le submit, la corrélation des DLR et le temps jusqu’au résultat.
• Conservez des textes légitimes, non trompeurs et adaptés aux politiques applicables.
• Faites varier une dimension à la fois : destination, opérateur, expéditeur, type de contenu ou route déclarée le cas échéant.
• Enregistrez la version du cas de test, l’heure, les identifiants, les réponses synchrones, les événements asynchrones et les observations.
• Ne transformez pas le résultat d’un test en garantie pour toutes les destinations, tous les expéditeurs ou tous les types de trafic.

Compléter avec la production sans mélanger les populations

Le trafic de production offre une couverture réelle de destinations, d’expéditeurs et de situations opérationnelles qu’un test synthétique ne reproduit pas. Il comporte toutefois de la variabilité : campagnes, pics d’OTP, changements de contenu, différences de consentement, comportement des terminaux et politiques applicables. Il sert donc à observer des tendances, mais exige une segmentation avant d’attribuer une cause à la route.

Conservez les résultats synthétiques et ceux de production comme des populations distinctes. Une baisse simultanée dans les deux groupes peut justifier une investigation prioritaire. Un écart observé uniquement en production peut nécessiter de vérifier d’abord les changements de mix, d’expéditeur, de contenu ou de destination avant de conclure à une dégradation de la connectivité ou de la livraison.

Le suivi doit conserver des identifiants persistants et réconcilier les événements asynchrones. En cas d’absence de callback, l’absence d’événement ne doit pas immédiatement devenir une conclusion ; lorsque l’interface disponible permet de consulter le statut, utilisez-la dans le cadre du processus de réconciliation.

• Étiquetez chaque enregistrement comme synthétique ou production.
• Segmentez la production par destination, opérateur lorsqu’il est connu, type de trafic, expéditeur, contenu ou modèle, et route déclarée le cas échéant.
• Ne comparez pas directement un test vers une seule destination avec une campagne multi-segments.
• Examinez le statut des messages sans résultat terminal dans la fenêtre opérationnelle définie.
• Conservez les preuves des changements de configuration, incidents et ajustements de trafic avec les métriques.

Métriques et tendances nécessitant une attention

Le tableau de bord doit présenter des séries distinctes par couche. Un seul chiffre de disponibilité peut masquer qu’un lien est sain alors que les submits sont rejetés, ou que les submits sont acceptés alors que la proportion de DLR finaux observés diminue.

Recherchez des évolutions par rapport à une référence comparable, et non seulement des valeurs absolues isolées. La comparaison a du sens lorsqu’elle conserve le même groupe de destination, le même opérateur s’il est disponible, le même expéditeur, le même profil de contenu, la même route déclarée et la même plage horaire. Les changements de mix peuvent produire un signal apparent de dégradation sans que la connectivité en soit la cause.

Parmi les tendances importantes figurent une connectivité stable avec une baisse des DLR, l’augmentation des rejets synchrones malgré des sessions saines, la croissance des requêtes en attente, l’allongement de la latence de submit ou de DLR, ainsi qu’une concentration de résultats défavorables dans une seule combinaison de destination, d’expéditeur ou de contenu.

• Connectivité : pourcentage de sessions opérationnelles, pertes de keepalive, reconnexions et latence de réponse.
• Acceptation : proportion de réponses satisfaisantes, rejets par code, timeouts, requêtes en attente et temps de réponse à l’envoi.
• Livraison : proportion de DLR final reçus, répartition des statuts, temps jusqu’au DLR et messages sans résultat réconcilié.
• Segmentation : destination au format E.164, opérateur lorsqu’il est disponible, expéditeur, type de trafic, contenu ou modèle, route déclarée et population de test ou de production.
• Preuves : identifiants corrélables, horodatages, codes d’erreur disponibles et changements opérationnels associés.