Numéros témoins en SMS A2P : des tests contrôlés pour évaluer les routes avec prudence
Comment concevoir un programme de numéros témoins pour observer l’acceptation, les DLR, la latence et le comportement des routes SMS A2P sans confondre un test synthétique avec une garantie de délivrabilité.
Qu’est-ce qu’un numéro témoin et que représente-t-il ?
Un numéro témoin est un numéro destinataire contrôlé ou utilisé avec une autorisation démontrable afin d’exécuter des tests de messagerie dans des conditions définies. Dans un programme de SMS A2P, il est attribué à une combinaison précise de pays, de réseau mobile, d’appareil, de type d’expéditeur et de cas d’usage légitime.
Il est préférable de stocker ou de normaliser le numéro au format E.164 afin de disposer d’une référence internationale cohérente pour la destination. Un inventaire doit également identifier le réseau prévu, l’état opérationnel du numéro, son titulaire ou l’autorisation correspondante, l’état du consentement lorsque cela s’applique, ainsi que l’historique des modifications.
Un numéro témoin ne constitue pas un échantillon représentatif des utilisateurs finaux. Il permet d’observer une combinaison contrôlée de variables, et non de démontrer la manière dont réagiront tous les terminaux, abonnés ou contextes réseau. Sa principale valeur réside dans la répétabilité : détecter les changements, incohérences et dégradations dans les conditions définies par l’équipe.
- Utilisez-le comme outil d’observabilité d’une route donnée.
- Ne le présentez pas comme une garantie commerciale de livraison.
- Conservez séparément le résultat de l’API, le DLR et l’observation sur l’appareil.
- Documentez tout changement de carte SIM, d’appareil, d’opérateur, de localisation opérationnelle ou de politique de test.
Questions opérationnelles auxquelles un test contrôlé peut répondre
Un test correctement instrumenté peut vérifier si la plateforme accepte une demande d’envoi, attribue un identifiant traçable, reçoit des mises à jour de statut et présente une cohérence entre les événements disponibles. Il peut aussi mesurer les intervalles observés entre la création du test, l’acceptation de l’envoi, les changements de statut et les preuves indépendantes enregistrées sur l’appareil.
La terminologie des statuts doit être interprétée avec précision. Les plateformes de messagerie distinguent généralement des étapes telles que la mise en file d’attente, l’envoi, l’acceptation par un opérateur en amont, la livraison confirmée et la non-livraison. L’acceptation d’une demande par une API, ou l’attribution d’un identifiant de message, ne prouve pas à elle seule que le terminal destinataire a reçu le SMS.
Lorsque l’équipe a accès à l’appareil témoin, elle peut enregistrer une observation indépendante de la réception. Dans certains cas, un signal ultérieur vérifiable et lié au message, comme l’utilisation d’un code OTP dans un environnement de test contrôlé, peut également apporter une preuve supplémentaire. Cette preuve doit être étiquetée comme distincte du DLR.
- La demande a-t-elle été acceptée et associée à un identifiant unique ?
- Des événements de statut ont-ils été reçus et sont-ils cohérents avec le flux attendu ?
- Quel délai s’est écoulé entre les événements observés ?
- Le message est-il apparu sur l’appareil contrôlé ?
- L’expéditeur et le contenu se sont-ils comportés comme prévu dans cette combinaison spécifique ?
- Le test était-il disponible pendant la période programmée ?
Ce que les numéros témoins ne peuvent pas démontrer à eux seuls
Un résultat positif sur un numéro témoin ne prouve pas la délivrabilité globale d’une route. Les conditions de livraison peuvent varier selon le filtrage de l’opérateur, la disponibilité du terminal, le comportement de l’appareil, le type d’expéditeur, le contenu, le moment d’envoi et des conditions de trafic absentes du test.
Un DLR de non-livraison ne doit pas non plus être automatiquement attribué à un problème de route. Il peut notamment résulter d’un filtrage du contenu par l’opérateur ou de l’indisponibilité du terminal destinataire. L’enquête doit partir des preuves disponibles et éviter les conclusions causales que le test ne permet pas d’étayer.
L’arrivée tardive d’un DLR exige une approche particulièrement prudente. À titre d’exemple de fenêtre documentée par un fournisseur, AWS indique que les DLR générés par les opérateurs peuvent être reçus jusqu’à 72 heures plus tard. Le moment où la plateforme reçoit le DLR ne doit donc pas être utilisé comme preuve que l’envoi sortant a été retardé pendant le même intervalle. En l’absence d’événement final, le résultat doit rester inconnu ou en attente conformément à la politique documentée du programme.
- N’inférez pas la réception sur le terminal à partir de la seule acceptation par l’API.
- N’assimilez pas un DLR à une observation indépendante lorsque celle-ci n’existe pas.
- Ne transformez pas un test isolé en conclusion concernant un réseau ou un pays entier.
- N’interprétez pas l’arrivée tardive d’un DLR comme un retard de livraison sans preuve supplémentaire.
- N’attribuez pas tous les échecs à la route sans examiner le contenu, le terminal et le contexte du test.
Concevez une matrice minimale et explicite de numéros témoins
La matrice doit être construite à partir des décisions que l’équipe doit prendre. Au lieu d’accumuler des numéros sans structure, définissez chaque cellule comme une combinaison de destination, de réseau mobile attendu, de type d’expéditeur, de profil de contenu et de cas d’usage légitime. Ajoutez un identifiant de version afin de savoir quelle configuration était en vigueur pour chaque test.
Commencez par une couverture pouvant être maintenue opérationnellement. Étendez la matrice lorsqu’une hypothèse précise existe : différence entre expéditeurs, doute concernant un opérateur, changement de comportement lié à l’encodage ou incident nécessitant une comparaison. L’extension doit accroître la capacité de discrimination du test, et non seulement le volume de messages.
Le réseau prévu dans l’inventaire doit être traité comme un attribut vérifiable et soumis à révision, et non comme une propriété permanente déduite uniquement du préfixe.
- Pays ou destination normalisée au format E.164.
- Réseau mobile attendu et date de la dernière vérification.
- Numéro témoin et état opérationnel.
- Type d’expéditeur utilisé dans le test.
- Profil de contenu et encodage prévu.
- Cas d’usage légitime : OTP de test, notification transactionnelle de test ou autre flux autorisé.
- Appareil et méthode d’observation indépendante, s’ils existent.
- Version de la matrice et responsable de sa maintenance.
Sélectionnez et maintenez les numéros témoins avec un contrôle des autorisations
N’intégrez que des numéros détenus par l’équipe ou bénéficiant d’une autorisation démontrable pour participer au programme. Si les messages ont une nature commerciale ou sont soumis à des exigences locales de consentement, d’identification et de désinscription, le programme doit conserver les preuves applicables. Selon la juridiction, la responsabilité de prouver le consentement peut incomber à l’expéditeur.
L’inventaire doit enregistrer au minimum l’identifiant du numéro, le fondement de l’autorisation, la date et la méthode d’obtention lorsqu’elles s’appliquent, l’état du consentement, la date d’ajout, le responsable interne, l’état de l’appareil et la date de la dernière vérification. Conservez également un historique des modifications et des suppressions.
Établissez des règles de remplacement. Un numéro doit être examiné ou remplacé s’il ne donne plus accès à l’appareil, n’est plus autorisé, change d’état opérationnel, présente des observations récurrentes impossibles à interpréter ou ne représente plus la cellule de matrice pour laquelle il a été intégré. Le remplacement ne doit pas effacer l’historique du numéro précédent.
- Limitez l’accès à l’inventaire et aux appareils témoins.
- Séparez l’autorisation d’utilisation, l’état technique et les résultats des tests.
- Enregistrez les suppressions, révocations et actions qui en découlent.
- Vérifiez régulièrement la disponibilité de l’appareil et la validité de l’autorisation.
- Maintenez la traçabilité entre un test historique et la version d’inventaire utilisée.
Concevez des messages de test permettant d’interpréter le résultat
Le message de test doit être identifiable, légitime et suffisamment stable pour permettre une comparaison entre les exécutions. Incluez un identifiant de test non sensible lorsque cela est nécessaire pour corréler l’observation sur l’appareil avec l’enregistrement de l’envoi. Évitez tout contenu contenant des données personnelles inutiles, de véritables identifiants ou des informations non indispensables à l’objectif technique.
Enregistrez l’encodage et la longueur du corps du message. Ce sont des variables importantes, car le nombre de segments transmis dépend de l’encodage et de la longueur. À titre de référence technique courante, les textes GSM-7 de plus de 160 caractères et les textes UCS-2 de plus de 70 caractères sont segmentés afin de tenter leur réassemblage. La documentation des fournisseurs indique que ce réassemblage n’est pas pris en charge de manière uniforme par tous les opérateurs et terminaux.
Testez séparément les profils que vous devez comparer. Par exemple, un message GSM-7 à un segment, un cas UCS-2 autorisé et un cas multiparties s’il est pertinent pour le trafic légitime géré par l’équipe. Ne modifiez pas simultanément l’expéditeur, le contenu, l’encodage et la route si l’objectif est d’identifier la cause d’une différence.
- Identifiant interne de test ne contenant aucune donnée personnelle.
- Texte stable et facile à reconnaître sur l’appareil.
- Encodage prévu et longueur du message.
- Nombre de segments attendu et observé lorsqu’il est disponible.
- Type et valeur d’expéditeur autorisés.
- Objectif technique du test et variables maintenues constantes.
- Interdiction d’utiliser des secrets, de vrais OTP ou des données sensibles dans le contenu de test.
Enregistrez les événements, les preuves et les temps par message
Chaque envoi doit pouvoir être reconstitué de bout en bout. Conservez un identifiant interne d’exécution et l’identifiant renvoyé par la plateforme ou le fournisseur lorsqu’il existe. Enregistrez les horodatages de création, d’envoi, de mises à jour de statut, de réception du DLR et d’observation indépendante sur l’appareil.
Distinguez le temps mesuré à chaque étape. L’intervalle entre la création et l’événement d’acceptation ou d’envoi décrit une partie de la chaîne. L’heure reçue dans un DLR peut refléter une date fournie par l’opérateur, tandis que la réception du DLR par la plateforme correspond à un autre instant. Ne fusionnez pas ces champs dans une métrique de latence unique sans en conserver la provenance.
Conservez les codes d’erreur, le statut brut lorsqu’il est disponible, les changements de statut et les preuves d’observation. Si l’appareil affiche le message, notez la méthode de vérification et le moment de l’observation. Si un signal ultérieur vérifiable est utilisé, enregistrez de quel signal il s’agit, comment il a été lié au message et quelles sont ses limites.
- ID interne du test et ID externe du message.
- Version de la route ou de la configuration, si elle est disponible en interne.
- Destination témoin, cellule de matrice et version de l’inventaire.
- Contenu ou empreinte de contenu autorisée par la politique de confidentialité.
- Encodage, longueur et segments.
- Expéditeur et cas d’usage.
- Statuts reçus, codes d’erreur et DLR brut lorsque nécessaire.
- Horodatages avec fuseau horaire et source de chaque marque temporelle clairement distinguée. L’observation sur l’appareil peut être classée comme oui, non, non disponible ou non vérifiable. Enregistrez également le résultat final classé et le niveau de preuve.
Traitez les DLR tardifs, les doublons et les contradictions sans exagérer les preuves
Définissez une machine à états interne avant d’exécuter des tests à grande échelle. Elle doit accepter les événements tardifs, les événements répétés et les changements de statut arrivant dans un ordre inattendu. Conservez l’historique complet ; ne remplacez pas un événement antérieur sans conserver la trace de la séquence reçue.
Si un DLR final arrive après la période opérationnelle d’observation, enregistrez-le comme événement tardif et mettez à jour la classification conformément à la politique, tout en préservant la première évaluation et ses horodatages. Si des DLR en double apparaissent, conservez-les à des fins d’audit et dédupliquez-les uniquement dans la couche analytique au moyen de règles explicites.
Lorsqu’un DLR et l’observation sur l’appareil ne concordent pas, ne forcez pas une explication. Classez le cas comme incohérent, vérifiez la corrélation des identifiants, l’horloge de l’appareil, le contenu et la méthode d’observation. S’il est impossible d’établir une correspondance fiable, n’affirmez ni réception indépendante ni défaillance de la route.
- En attente : aucun événement final n’existe encore dans la fenêtre définie.
- Final signalé : un DLR ou un statut final a été reçu.
- Observé sur l’appareil : une preuve indépendante documentée existe.
- Incohérent : les sources disponibles ne permettent pas une interprétation unique.
- Inconnu : aucune preuve finale suffisante n’est disponible après la fenêtre applicable.
- Tardif : l’événement est arrivé après la fenêtre opérationnelle et doit être conservé séparément.
Questions fréquentes
Un DLR « delivered » prouve-t-il que le SMS a été vu par l’utilisateur ?
Pas nécessairement. Un DLR est un signal de statut reçu via la chaîne de messagerie. Il doit être distingué d’une observation indépendante sur l’appareil ou d’un autre signal ultérieur vérifiable lié au message. Les preuves disponibles et leur origine doivent être enregistrées séparément.
Combien de numéros témoins faut-il par opérateur ?
Il n’existe pas de nombre universel vérifiable. Définissez la quantité selon les combinaisons à observer : destination, réseau mobile attendu, expéditeur, contenu et cas d’usage légitime. Commencez par une matrice maintenable et étendez-la lorsqu’une hypothèse opérationnelle requiert une plus grande capacité de discrimination.
Un test avec numéro témoin peut-il mesurer la latence réelle de livraison ?
Il peut mesurer des intervalles observés entre les événements, mais vous devez identifier la source de chaque horodatage. L’arrivée d’un DLR sur la plateforme ne prouve pas à elle seule le moment de livraison au terminal ni un retard de l’envoi sortant.
Pourquoi enregistrer l’encodage et les segments ?
Parce que GSM-7 et UCS-2 ont des seuils de segmentation différents, et que les messages longs peuvent nécessiter un réassemblage. La documentation des fournisseurs indique que ce comportement n’est pas pris en charge de manière uniforme par tous les opérateurs et terminaux.
Une recherche HLR confirme-t-elle qu’un numéro peut recevoir un SMS ?
Non. Une recherche HLR ne démontre ni le consentement, ni l’identité, ni la titularité, ni une livraison garantie. Elle doit être traitée comme une source d’information distincte de l’autorisation d’utilisation, des événements d’envoi et de l’observation de réception.
Qu’est-ce qui doit déclencher une enquête sur une route ?
Un écart répété par rapport à une référence définie, une perte de cohérence entre les DLR et l’observation indépendante, des changements persistants par cellule de matrice ou une dégradation qui ne peut être expliquée par la disponibilité de l’appareil, le contenu ou un changement documenté de configuration. Avant d’attribuer la cause à la route, répétez des tests contrôlés et élargissez l’échantillon de manière ciblée.
Sources consultées
- E.164: The international public telecommunication numbering planInternational Telecommunication Union (ITU)
- AWS End User Messaging SMS User GuideAmazon Web Services
- Messages resourceTwilio
- Frequently Asked Questions about Canada's Anti-Spam LegislationCanadian Radio-television and Telecommunications Commission (CRTC)
- From Canada’s Anti-Spam Legislation (CASL) Guidance on Implied ConsentCanadian Radio-television and Telecommunications Commission (CRTC)