Comment comparer les fournisseurs de SMS A2P avec un modèle de preuve

Pourquoi le prix et un DLR déclaré ne suffisent pas

Comparer les fournisseurs de SMS A2P uniquement selon le prix, la couverture déclarée ou un taux de livraison agrégé introduit un risque opérationnel. Ces indicateurs peuvent masquer des différences entre pays, réseaux mobiles, identités d’expéditeur, types de trafic et conditions d’exploitation.

Une route peut accepter un envoi dans l’API et renvoyer une réponse initiale correcte sans que cela décrive le résultat final communiqué par le réseau. De même, un statut final de livraison communiqué par un fournisseur ne doit pas être présenté comme une vérification indépendante que le destinataire a vu le message sur son terminal.

La décision d’approvisionnement doit dissocier le coût de la preuve. Une offre n’est comparable que lorsque l’on sait quelles destinations elle couvre réellement, quel trafic elle accepte, quelle identité d’expéditeur elle autorise, comment elle communique ses statuts et quelles restrictions elle applique.

• Ne considérez pas l’acceptation initiale d’une API comme une preuve de livraison.
• N’agrégez pas les résultats de pays ou de réseaux différents dans un pourcentage unique.
• Ne supposez pas qu’un Sender ID est pris en charge ou visible dans toutes les destinations.
• N’acceptez pas une affirmation de couverture sans conditions opérationnelles associées.

Le modèle d’évaluation : déclaration, documentation et observation

Un modèle utile distingue trois niveaux d’information. Le premier est la déclaration du fournisseur : couverture, types de messages, capacité, identité d’expéditeur et statuts disponibles. Elle sert à la préqualification, mais ne constitue pas une preuve suffisante pour la production.

Le deuxième niveau est la preuve documentaire : conditions de service, restrictions par destination, spécification API ou SMPP, catalogue des statuts, politique de Sender ID, limites applicables et correspondance des erreurs. Cette documentation permet de transformer une promesse commerciale en exigences vérifiables.

Le troisième niveau est l’observation indépendante. Il comprend des tests contrôlés, vos propres journaux d’envoi et, lorsque cela est réalisable et autorisé, l’observation de la réception ou de l’affichage sur des terminaux de test. Cette observation ne prouve pas qu’un destinataire a lu le message ; elle consigne seulement ce qui a été observé sur l’appareil de test dans ces conditions. Elle doit être liée à une destination, un réseau, un contenu, une identité d’expéditeur et une fenêtre temporelle précis.

• Déclaration : ce que le fournisseur affirme pouvoir faire.
• Documentation : comment il définit, limite et communique ce service.
• Observation : ce qui s’est produit dans un test identifiable et reproductible.
• Décision : quel usage est autorisé, avec quelles limites et jusqu’à quelle date la preuve reste valable.

Quatre dimensions à évaluer séparément

La comparaison est plus fiable lorsqu’elle est divisée en quatre dimensions. Chacune répond à une question différente et exige une preuve différente.

Premièrement, la conformité et les restrictions : déterminez quel trafic légitime la route accepte, quelles exigences existent pour les expéditeurs, les modèles, les préenregistrements ou les registres locaux, ainsi que les conditions applicables au pays de destination. La prise en charge du Sender ID et ses exigences ne sont pas universelles ; certains marchés exigent un préenregistrement et d’autres n’affichent pas le Sender ID au destinataire. Les exigences applicables peuvent également varier selon le type d’expéditeur, l’entité qui envoie, le contenu, l’enregistrement et la relation contractuelle. Confirmez les conditions locales auprès de sources réglementaires, d’opérateurs ou de conseils compétents.

Deuxièmement, la connectivité et l’exploitation : validez la méthode de connexion disponible, les champs obligatoires, la gestion des identifiants, les statuts asynchrones, la consultation des messages et la documentation des erreurs. En SMPP, les erreurs de réseau ou de SMSC peuvent être spécifiques à chaque réseau ou implémentation ; le fournisseur doit donc expliquer leur correspondance.

Troisièmement, la capacité et la continuité : distinguez l’acceptation de l’envoi, le temps passé en file d’attente et le résultat final. Une plateforme peut enregistrer ces dimensions séparément ; aucune d’elles, prise isolément, ne démontre que la capacité sera représentative de toutes les destinations ou de tous les scénarios de production.

Quatrièmement, la qualité observable : mesurez des résultats segmentés, la séquence des statuts, la latence et le comportement du contenu et de l’expéditeur. En tant que méthodologie d’évaluation, segmentez par pays, réseau de destination lorsqu’il est disponible et identité d’expéditeur lorsque cela est pertinent. L’évaluation doit refléter ce qui a été observé, sans étendre un échantillon limité à une garantie générale.

• Conformité et restrictions : cas d’usage, consentement ou autre base autorisante applicable, origine et exigences locales.
• Connectivité et exploitation : HTTP ou SMPP, callbacks, consultation des statuts, corrélation et erreurs.
• Capacité et continuité : acceptation, file d’attente, disponibilité et incidents.
• Qualité observable : statuts, délais, segments, comportement par réseau et observation indépendante lorsqu’elle est réalisée.

Informations minimales à demander avant de tester une route

Avant de commencer les tests, demandez une fiche de préqualification par destination. Comme pratique de normalisation interne, enregistrez la destination au format E.164 et associez-la, lorsque cela est possible, au pays et au réseau mobile indiqués par la plateforme, le réseau ou l’instrumentation de test. Cette donnée n’est pas toujours disponible et peut ne pas représenter l’opérateur effectif dans des scénarios de portabilité. L’interface ou le flux du fournisseur peut exiger des transformations ou un format différent ; son exigence technique doit donc être confirmée. Cette normalisation évite de mélanger des résultats qui ne sont pas comparables.

Demandez au fournisseur de décrire quels types de trafic légitime il accepte : par exemple, OTP, transactionnel ou marketing avec consentement. Il doit aussi indiquer les identités d’expéditeur autorisées, les restrictions de Sender ID, les exigences de préenregistrement, les modèles applicables et toute condition spécifique au marché.

Demandez le catalogue des statuts de message, la signification de chaque statut, le canal de remise des événements asynchrones ou le mécanisme de consultation, les identifiants disponibles et la correspondance des codes d’erreur. Si le fournisseur communique des limites opérationnelles, elles doivent être associées à la destination et au type de trafic auxquels elles s’appliquent.

• Pays de destination et numéros de test normalisés en interne au format E.164.
• Type de trafic accepté et cas d’usage exclus.
• Identité d’expéditeur autorisée et conditions de Sender ID.
• Exigences réglementaires, enregistrements ou modèles applicables.
• Statuts DLR, sémantique de chaque statut et méthode de consultation ou callback.
• Identifiant du fournisseur, identifiant de corrélation et correspondance des erreurs.
• Conditions opérationnelles et date de validité des informations.

Comment concevoir des tests contrôlés sans transformer un échantillon en garantie

Un test doit répondre à une question précise. Par exemple : déterminer si un expéditeur particulier est accepté pour du trafic OTP légitime vers un réseau donné, si des statuts finaux corrélables sont reçus ou si un message en plusieurs parties conserve le comportement attendu. N’essayez pas de démontrer la qualité globale d’une route avec une seule campagne de test.

Définissez à l’avance l’ensemble des destinations, la période d’observation, les cas d’usage, les identités d’expéditeur, les contenus autorisés et les terminaux de test. Maintenez constants les éléments que vous n’évaluez pas. Si vous modifiez simultanément le contenu, l’expéditeur et la destination, vous ne pourrez pas attribuer le résultat.

Incluez des messages en une et plusieurs parties et enregistrez l’encodage utilisé. En SMPP, data_coding identifie le schéma d’encodage. La segmentation et les limites effectives dépendent aussi d’éléments tels que l’UDH ou le SAR, l’alphabet utilisé, l’interface du fournisseur, l’implémentation du SMSC et le réseau. Un test de contenu court ne valide donc pas à lui seul les messages segmentés ou utilisant un autre encodage.

Pour les OTP, établissez une fenêtre temporelle d’évaluation explicite et préparez une solution de continuité opérationnelle. Les accusés de livraison sont asynchrones et la livraison peut être retardée si le terminal n’est pas disponible. Un DLR tardif ne doit pas être interprété automatiquement comme un signal suffisant pour un cas d’usage sensible au temps.

• Formulez une hypothèse précise par test.
• Segmentez par pays, réseau, cas d’usage et identité d’expéditeur.
• Testez une et plusieurs parties, avec l’encodage enregistré.
• Utilisez un contenu légitime, autorisé et représentatif du cas d’usage.
• Définissez une fenêtre d’observation avant l’envoi.
• N’extrapolez pas l’échantillon à des destinations, réseaux ou volumes non testés.

Ce qu’il faut enregistrer dans chaque test

La traçabilité dépend de la capacité à reconstruire l’historique de chaque message. Conservez à la fois l’identifiant attribué par le fournisseur et un identifiant de corrélation interne. En SMPP, une référence attribuée par l’ESME peut être utilisée, et l’accusé de livraison peut inclure l’identifiant que le SMSC a attribué au message d’origine. L’utilisation et le renvoi effectif de ces références ou champs dépendent de l’implémentation du SMSC ou du fournisseur.

Enregistrez les horodatages d’acceptation de l’envoi, les changements de statut, le statut final et la réception observée lorsqu’elle a été réalisée. Le format d’accusé de livraison décrit dans SMPP comprend submit date et done date, bien que le format concret puisse varier selon le SMSC ou le fournisseur. Done date indique le moment où le message a atteint un statut final. Ces temps permettent de distinguer l’acceptation technique, l’évolution du message et les preuves indépendantes disponibles.

Le registre doit préserver le contexte. Sans la destination, le réseau indiqué par la plateforme, le réseau ou l’instrumentation de test lorsqu’il est disponible, l’expéditeur, le contenu ou l’empreinte de contenu, l’encodage, le nombre de segments et le cas d’usage, il est impossible d’interpréter correctement un statut ou de comparer des tests ultérieurs. La preuve du consentement ou d’une autre base autorisante doit être conservée conformément à la réglementation, à la finalité et à la juridiction applicables.

• ID de corrélation interne.
• ID du message du fournisseur ou du SMSC.
• Numéro de destination normalisé en interne au format E.164.
• Pays et réseau de destination indiqués par la plateforme, le réseau ou l’instrumentation de test lorsqu’ils sont disponibles.
• Cas d’usage et preuve de consentement ou autre base autorisante applicable, conservée conformément à la réglementation, à la finalité et à la juridiction applicables.
• Contenu testé ou empreinte permettant de l’identifier sans exposer de données inutiles.
• Sender ID ou identité d’expéditeur.
• Encodage et nombre de segments envoyés et observés lorsque cette donnée est exposée, si cela correspond au test effectué ; ne transformez pas un test en une partie en preuve concernant des messages segmentés ou utilisant un autre encodage. (La spécification SMPP explicite le lien entre data_coding, les limites de charge utile et le comportement dépendant du réseau ou du SMSC.)

Comment interpréter les DLR, la latence et la disponibilité

Les DLR sont des signaux opérationnels précieux, mais leur signification dépend de l’interface et du fournisseur. SMPP définit notamment des statuts finaux tels que DELIVRD, EXPIRED, UNDELIV et REJECTD, et prévoit également DELETED et UNKNOWN. Le format concret de l’accusé peut être spécifique au fournisseur ou au SMSC. La fiche d’évaluation doit documenter comment chaque statut et chaque code sont traduits en cause opérationnelle.

Ne confondez pas des statuts différents. Par exemple, dans une nomenclature spécifique à un fournisseur, un statut d’acceptation peut représenter l’acceptation par un fournisseur en amont, tandis qu’un statut de livraison peut dépendre de la confirmation disponible auprès de l’opérateur et, lorsqu’elle existe, du terminal de destination. Il ne s’agit pas d’une définition universelle de SMPP ni de tous les DLR : la nomenclature et sa sémantique sont propres à chaque fournisseur et doivent être vérifiées dans sa documentation. Même lorsqu’une confirmation de l’opérateur ou du terminal est documentée, elle n’équivaut pas à une observation indépendante de l’appareil réalisée par l’équipe d’évaluation et ne prouve pas que le destinataire a lu le message. Aucun statut ne doit remplacer l’observation indépendante lorsqu’elle est nécessaire pour valider une hypothèse de test.

Mesurez la latence par étapes : moment de l’envoi, acceptation, dernier statut reçu, statut final et réception observée, le cas échéant. Rapporter une moyenne unique peut masquer des retards importants pour un flux OTP. Pour le marketing avec consentement, les critères temporels peuvent être différents, mais ils doivent eux aussi être définis avant le test.

La disponibilité doit être observée en même temps que les incidents et la reprise. Enregistrez les rejets, les échecs de connexion, les pertes ou retards d’événements, les changements de sémantique et les différences entre consultation et callback. Une route qui semble disponible mais n’offre pas une traçabilité suffisante peut ne pas convenir à un cas d’usage nécessitant un audit.

• Classez chaque métrique selon l’étape du cycle de vie du message.
• Conservez la séquence des changements de statut, et pas uniquement le dernier statut.
• Demandez la correspondance documentée des erreurs et statuts spécifiques au fournisseur.
• Analysez les résultats par segment de destination, et non uniquement sous forme agrégée.
• Distinguez les preuves de statut communiqué et de réception observée.

Fiche d’évaluation du fournisseur et critères de décision

La fiche d’évaluation doit transformer la comparaison en une décision révisable. Pour chaque question, indiquez quelles preuves sont acceptées, qui les valide en interne, quand elles ont été obtenues et quand elles expirent. Une affirmation non vérifiée doit rester marquée comme une déclaration, et non comme une capacité approuvée.

Définissez un résultat par cas d’usage et par destination : approuvé, approuvé avec restrictions, en attente de preuves ou rejeté. Évitez une approbation générique pour l’ensemble du fournisseur. Une même contrepartie peut convenir à un flux transactionnel dans une destination et ne pas être validée pour le Sender ID, le marketing avec consentement ou le trafic OTP dans une autre.

Les preuves doivent être revues périodiquement. Les paramètres de callback et les ensembles de propriétés des événements peuvent évoluer, et les restrictions opérationnelles peuvent également changer. Concevez des intégrations tolérantes aux paramètres supplémentaires et maintenez une date d’expiration pour la documentation et les tests.

• Question : quelle destination, quel type de trafic et quelle identité d’expéditeur sont évalués ?
• Preuve acceptable : documentation à jour, journaux de test et statuts corrélés.
• Résultat : approuvé, restreint, en attente ou rejeté.
• Conditions : limites d’utilisation, exigences relatives à l’expéditeur, au contenu ou à l’enregistrement.
• Contrôle : date de revue et responsable interne.
• Suivi : incidents ouverts, changements détectés et tests de régression nécessaires.