Choisir un Sender ID A2P SMS selon la destination : guide de validation
Transformez les exigences locales relatives à l’expéditeur SMS en critères documentés et en tests par destination. Apprenez à distinguer les déclarations d’un fournisseur du comportement observé sur la route et sur le terminal.
Pourquoi l’expéditeur doit faire partie de la décision de routage
Le Sender ID n’est pas un attribut dont la validité peut être considérée comme universelle. L’identité affichée au destinataire dépend, entre autres facteurs, des capacités des réseaux mobiles du pays de destination. Par conséquent, le fait qu’un expéditeur ait fonctionné sur un marché ne prouve pas qu’il s’affichera ou se comportera de la même manière sur un autre.
Lors de l’évaluation d’une route, consignez l’expéditeur attendu avec la destination et le type de trafic légitime prévu. Le fait qu’une route accepte un message ne confirme pas à lui seul que l’identité demandée a été conservée ni que le SMS est arrivé sur le terminal.
- Évaluez l’identité de l’expéditeur par pays et, lorsque l’information est disponible, par opérateur et par route.
- Distinguez les conditions communiquées par un fournisseur des résultats observés lors de vos propres tests.
- Ne considérez pas l’acceptation technique, un DLR et la réception sur un terminal comme des états équivalents.
Types d’expéditeurs et différences opérationnelles selon les destinations
Les expéditeurs alphanumériques constituent une catégorie reconnue dans la documentation SMS. Des identités numériques ou d’autres modalités soumises aux conditions du marché peuvent également exister. Toutefois, les informations disponibles ne permettent pas d’affirmer quels types sont autorisés, disponibles ou soumis à enregistrement dans chaque pays.
Ne partez pas du principe qu’une identité valide dans une destination est acceptée dans une autre. Avant d’acheminer du trafic, confirmez la modalité précise auprès de sources officielles et du fournisseur de la route. La documentation générale sur les identités de l’expéditeur ne remplace pas les règles locales.
- Notez le type d’identité envisagé et le format exact envoyé.
- Vérifiez séparément si elle est autorisée, si un enregistrement est requis et si le fournisseur accepte son utilisation sur la route proposée.
- Ne déduisez pas les exigences locales d’une norme générale de numérotation ni de votre expérience dans un autre pays.
Exigences à confirmer auprès des sources officielles et des fournisseurs
Avant d’activer le trafic, consultez le régulateur concerné ainsi que la documentation officielle disponible des opérateurs ou des organismes du secteur qui publient des règles applicables. Demandez au fournisseur quelles conditions il indique pour la destination et faites préciser leur portée : pays, opérateur, route, type d’expéditeur et catégorie de trafic.
Distinguez les sources : une déclaration commerciale du fournisseur est une information à vérifier ; une règle ou une instruction officielle constitue une référence relative aux exigences ; un test de trafic apporte des éléments sur le comportement observé dans des conditions précises. Aucune de ces catégories ne doit être présentée comme prouvant automatiquement les autres.
- Confirmez si l’expéditeur proposé est autorisé et s’il existe des conditions d’enregistrement ou d’autorisation.
- Demandez quels opérateurs et quelles routes sont couverts par la déclaration du fournisseur, et quelles limites s’appliquent.
- Consignez la source consultée, la date de vérification et toute réponse reçue.
- Si la règle n’est pas claire, reportez l’activation ou limitez le test jusqu’à ce que l’incertitude soit levée.
Documenter le pays, l’opérateur, le trafic autorisé et les éléments de preuve
Créez une fiche par destination et évitez de regrouper sur une seule ligne des conditions susceptibles de varier selon l’opérateur ou la route. Indiquez quelles informations proviennent d’une source officielle, lesquelles ont été déclarées par le fournisseur et lesquelles ont été observées lors d’un test. Si un champ n’est pas confirmé, marquez-le comme étant en attente, et non comme autorisé.
Dans vos contrôles internes, indiquez l’objectif du message et le fondement de l’autorisation applicable. Les tests doivent utiliser des messages légitimes et envoyés avec le consentement requis, dans le respect des règles en vigueur. Les preuves issues d’un test ne remplacent pas le respect des obligations relatives à la messagerie.
- Destination et, si elle est connue, opérateur et route évalués.
- Type et format exact du Sender ID.
- Type de trafic et condition d’utilisation déclarée ou confirmée.
- Exigence applicable, source, date de consultation et personne responsable de la vérification.
- Déclaration du fournisseur, portée et limites explicites.
- Date du test, configuration, résultat observé et niveau de confiance accordé aux éléments de preuve.
Plan de validation : expéditeur, contenu avec consentement, destination et résultat
Concevez un test contrôlé permettant de savoir ce qui a été envoyé et ce qui a été observé. Gardez la route et le contenu constants lorsque vous évaluez une identité précise ; si vous modifiez plusieurs conditions en même temps, il sera plus difficile d’attribuer le résultat. Effectuez des tests uniquement auprès de destinataires ayant accepté de les recevoir et avec un contenu conforme aux règles applicables.
Une séquence pratique consiste à confirmer d’abord les exigences, à convenir avec le fournisseur de la route et de la destination du test, à envoyer un message autorisé avec l’expéditeur prévu, puis à consigner la réponse du système et l’observation sur le terminal, si elle est disponible. Répétez la validation en cas de changement de route, d’opérateur, d’expéditeur ou de conditions applicables.
- Définissez à l’avance ce que vous souhaitez vérifier : acceptation, identité affichée ou réception sur le terminal.
- Consignez la destination, la route, le Sender ID exact, le contenu du test et l’heure d’envoi.
- Dans la mesure du possible, utilisez un terminal de test autorisé et consignez ce qui s’y affiche réellement.
- Ne généralisez pas le résultat à d’autres opérateurs, routes ou pays sans éléments de preuve.
Acceptation technique, DLR et réception vérifiée sur le terminal
L’acceptation technique indique qu’un système a reçu ou traité une requête à une étape du flux ; elle ne prouve pas nécessairement que le message a été remis au destinataire. Un DLR est un état communiqué par la chaîne de messagerie et doit être consigné comme tel, sans être présenté comme une vérification indépendante du terminal.
Pour vérifier la réception, il faut observer directement le terminal du destinataire ou recourir à un mécanisme de vérification convenu et documenté. Même dans ce cas, les éléments de preuve se limitent à cet envoi, à cette destination, à cette route et à ce moment précis. Si aucune observation du terminal n’est disponible, indiquez explicitement que la réception n’a pas été vérifiée.
- Étiquetez chaque résultat comme acceptation technique, DLR reçu ou observation sur le terminal.
- Conservez l’état d’origine et la provenance des éléments de preuve ; ne transformez pas un état communiqué en garantie.
- Indiquez comme inconnu tout résultat qui ne peut pas être confirmé.
Procédure en cas de changement, de rejet ou de comportement incohérent
Si un expéditeur est rejeté, modifié ou ne s’affiche pas comme prévu, suspendez l’extension du trafic concerné et conservez les données relatives à l’envoi. Vérifiez si l’exigence locale a changé, si le fournisseur a modifié la route ou si le test a été effectué dans des conditions différentes. Demandez des précisions au fournisseur et, si nécessaire, consultez de nouveau la source officielle pertinente.
N’essayez pas de contourner les restrictions en modifiant de manière improvisée l’identité ou le contenu. Ne reprenez le trafic qu’une fois la situation clarifiée et la configuration validée pour la destination concernée.
- Isolez le cas par destination, opérateur, route, expéditeur et date.
- Comparez la configuration avec celle du dernier test documenté.
- Consignez le rejet ou l’écart et transmettez-le au fournisseur avec des éléments de preuve suffisants.
- Mettez à jour la fiche et effectuez une nouvelle validation avant d’étendre le trafic en production.
Modèle de fiche et liste de contrôle avant la mise en production
Une fiche concise, tenue à jour pour chaque destination, aide à éviter qu’une déclaration générale ne devienne une hypothèse opérationnelle. Indiquez clairement ce qui est confirmé, ce qui a été déclaré par le fournisseur et ce qui reste à vérifier. Réexaminez la fiche lorsque les règles, le fournisseur, la route ou le comportement observé changent.
Avant d’activer le trafic, confirmez que le cas d’usage est légitime et que les destinataires ont donné le consentement requis ; que les conditions relatives à l’expéditeur ont été vérifiées auprès des sources pertinentes ; et que le test distingue et documente l’acceptation technique, le DLR et la réception sur le terminal.
- Destination et opérateur identifiés, avec une portée de validation clairement définie.
- Expéditeur et format documentés ; exigences et nécessité d’un enregistrement confirmées ou signalées comme étant en attente.
- Source officielle consultée et déclaration du fournisseur archivées séparément.
- Test autorisé effectué et résultat observé consigné sans extrapolation.
- Responsable, date de révision et conditions de renouvellement de la validation définis.
- Aucune garantie de livraison ni affirmation de conformité fondée uniquement sur une acceptation ou un DLR.
Questions fréquentes
Un Sender ID accepté dans un pays fonctionnera-t-il dans un autre ?
Il ne faut pas le supposer. Les capacités des réseaux mobiles du pays de destination influent sur l’identité susceptible d’être affichée. Confirmez les conditions pour chaque destination et validez la route concernée.
Un identifiant alphanumérique est-il autorisé sur tous les marchés ?
La documentation générale reconnaît les identifiants alphanumériques, mais cela ne prouve ni leur disponibilité ni leur autorisation universelle. Consultez les règles applicables au pays et à l’opérateur.
Un DLR prouve-t-il que le SMS est arrivé sur le téléphone ?
Pas à lui seul. Consignez le DLR comme un état communiqué par la chaîne de messagerie. La réception sur le terminal exige des éléments de preuve indépendants et documentés.
Que faire si le fournisseur confirme une condition que je ne trouve pas dans une source officielle ?
Consignez cette affirmation comme une déclaration du fournisseur, demandez-en la portée et les justificatifs, puis consultez le régulateur ou la documentation officielle pertinente. Tant qu’elle n’est pas vérifiée, ne la présentez pas comme une exigence officielle confirmée.
Un test réussi garantit-il les livraisons futures ?
Non. Il documente uniquement le comportement observé dans les conditions précises de ce test. Renouvelez la validation si la destination, l’opérateur, la route, l’expéditeur ou les exigences changent.
Sources consultées
- Elección de una identidad de origenAmazon Web Services
- Introducción a SMSMicrosoft Learn
- Especificaciones por series3GPP
- Recomendación E.164Unión Internacional de Telecomunicaciones (ITU-T)
- Recursos sobre redesGSMA