Comment planifier un lancement international de SMS A2P marché par marché
Une proposition de processus pour organiser un lancement international de SMS A2P par pays et par opérateur. Identifiez les données confirmées et les points à valider avant la mise en production.

Pourquoi un plan global nécessite des décisions par marché
Les éléments disponibles ne permettent pas de confirmer l’existence de règles uniformes en matière d’enregistrement, de contenu, d’acheminement ou de livraison applicables à tous les pays et à tous les opérateurs. Un processus marché par marché peut donc servir de proposition de planification, et non de description d’obligations ou de pratiques universelles.
À titre de recommandation, considérez chaque combinaison de pays, d’opérateur, de cas d’usage et d’expéditeur comme un point à examiner avant la mise en production. L’objectif serait de distinguer ce qui est confirmé de ce qui reste à vérifier.
- Séparez les faits confirmés des déclarations de tiers et des points en attente.
- Ne considérez pas une liste de couverture comme une preuve de connectivité active ou de délivrabilité.
- Distinguez l’acceptation d’un message, un DLR et une vérification indépendante de sa réception sur l’appareil.

Créez une fiche de lancement par pays
Comme proposition d’organisation, commencez par définir le périmètre métier et préparez une fiche pour chaque destination. Elle pourrait inclure le cas d’usage prévu — OTP, transactionnel ou marketing —, l’origine du trafic, les expéditeurs envisagés et les responsables techniques, commerciaux et conformité.
N’ajoutez des opérateurs cibles que si une source permet de les identifier. Si vous indiquez des volumes, présentez-les comme des estimations internes et non comme une capacité validée. Vous pouvez également consigner les informations inconnues et désigner une personne chargée de les examiner.
- Pays et opérateurs cibles, avec la source et la date des informations.
- Cas d’usage, exemple de contenu et expéditeur prévu.
- Volume et profil de trafic estimés, avec les hypothèses documentées.
- Interlocuteur chargé de confirmer chaque condition.
- Statut de chaque point : confirmé, déclaré par un tiers, en test ou en attente.

Renseignez-vous sur les expéditeurs, l’enregistrement et le contenu auprès de sources adaptées
Les éléments fournis ne permettent pas d’établir les exigences propres à chaque pays concernant les Sender ID, l’enregistrement des expéditeurs ou le contenu. Ne les déduisez pas de votre expérience sur un autre marché.
À titre de recommandation, consultez les sources officielles pertinentes, telles que les autorités compétentes ou la documentation officielle des opérateurs. Consignez la portée des informations recueillies et leur date. Si les sources manquent de clarté ou se contredisent, indiquez que le point n’est pas résolu plutôt que de le présenter comme une règle générale.
- Vérifiez quels expéditeurs peuvent être utilisés et si un enregistrement ou une approbation est mentionné.
- Vérifiez si les informations disponibles distinguent les cas d’usage ou les contenus.
- Pour les messages destinés aux utilisateurs, tenez compte du consentement et des règles applicables.
- Envisagez de reporter la mise en production si une condition essentielle au lancement reste à confirmer.
Distinguez couverture, connectivité et livraison observée
Les éléments disponibles ne suffisent pas à vérifier les procédures ou les conditions de couverture A2P selon les destinations. Sur le plan conceptuel, la couverture annoncée, la connectivité disponible et la livraison observée sont des notions distinctes ; aucune ne garantit à elle seule les livraisons futures.
Pour évaluer une offre précise, demandez, à titre de recommandation, que les opérateurs, le type de connexion et les limites connues soient spécifiés. Interprétez les résultats des tests en fonction des conditions dans lesquelles ils ont été obtenus, sans en faire une promesse universelle.
- Vérifiez quels opérateurs et expéditeurs sont couverts par les informations disponibles.
- Examinez si la route et la connectivité sont adaptées au cas d’usage prévu.
- Consignez les conditions et la date de chaque test ; ne généralisez pas un résultat à d’autres opérateurs ou expéditeurs.
Examinez l’intégration, la capacité et le traitement des DLR
Les éléments fournis ne permettent pas de confirmer les exigences d’intégration, la capacité, les délais d’expiration ni le comportement des accusés de livraison pour un lancement international A2P. Il n’est donc pas possible d’établir ici des paramètres techniques précis.
À titre de proposition de planification, documentez la connexion qui serait utilisée et les éléments confirmés par chaque interface. Avant l’intégration, clarifiez comment les messages seront identifiés, comment les DLR seront reçus et corrélés, et comment les statuts absents ou tardifs seront traités. Un DLR est un signal rapporté par la chaîne de messagerie : à lui seul, il ne prouve pas qu’une personne a vu le message ni que sa réception sur le téléphone a été vérifiée de manière indépendante.
- Confirmez l’interface, les paramètres, l’authentification et les responsabilités du support pour la connexion choisie.
- Demandez des informations sur les limites de capacité applicables et la gestion des pics ; ne présumez pas de valeurs ou de seuils.
- Convenez de la définition de l’expiration, des nouvelles tentatives et des statuts finaux, si ces éléments font partie de l’implémentation.
- Envisagez de vérifier la corrélation entre l’envoi et le DLR, et de documenter les cas sans accusé ou avec un statut ambigu.
Concevez des tests contrôlés par destination et par configuration
Les éléments disponibles ne définissent pas de protocole de test pour les lancements A2P internationaux. À titre de proposition de travail, les résultats peuvent être organisés par pays, par opérateur lorsque celui-ci peut être identifié, par expéditeur, par type de message et par connexion.
Pour un test contrôlé, convenez à l’avance des preuves à recueillir et de la manière de les interpréter. Consignez les conditions de l’essai avec les résultats. Ne qualifiez pas une réponse système de livraison vérifiée s’il n’existe pas de contrôle indépendant de la réception.
- Testez le message et l’expéditeur prévus si l’objectif est de représenter la configuration de production.
- Distinguez les tests de connectivité des tests portant sur le comportement de livraison.
- Conservez les horodatages, les identifiants permettant la corrélation, les réponses et les DLR disponibles.
- Interprétez les tests dans leur contexte ; un échantillon ne suffit pas à établir les performances futures.
Définissez les critères d’approbation et de retour en arrière
Les éléments disponibles ne permettent pas de définir des seuils universels pour approuver un lancement A2P international. À titre de proposition, définissez les critères avec les équipes responsables et le fournisseur avant d’effectuer les tests, en veillant à ce qu’ils puissent être évalués à partir des données disponibles et qu’ils correspondent au cas d’usage.
Il peut également être utile de documenter les personnes qui autorisent le lancement, les signaux qui entraîneraient une suspension et la manière de revenir à la situation précédente. Pour les OTP ou d’autres messages sensibles au facteur temps, convenez du comportement de secours de l’application sans attribuer à une route une garantie qui n’a pas été établie.
- Approbation : exigences pertinentes examinées et expéditeur évalué pour l’usage prévu.
- Approbation technique : intégration, corrélation des DLR et limites connues examinées.
- Approbation opérationnelle : tests examinés, responsables désignés et support identifié.
- Suspension ou retour en arrière : conditions observables, autorité décisionnaire et procédure convenues avant la mise en production.
Conservez les preuves et réexaminez les conditions
À titre de recommandation d’organisation, tenez un registre par marché des sources consultées, des réponses reçues, des versions de configuration, des messages testés et des résultats. Indiquez les dates et le périmètre pour distinguer les éléments confirmés des points en attente.
Réexaminez le registre si l’expéditeur, le contenu, le cas d’usage, la connexion ou la destination change. Les informations associées à une configuration ne doivent pas être automatiquement transférées à une autre. Les éléments fournis ne permettent pas de confirmer l’existence d’outils opérationnels précis pour découvrir, comparer ou gérer la capacité A2P.
- Conservez les preuves avec la décision qu’elles étayent et le nom de la personne qui l’a approuvée.
- Identifiez clairement les déclarations de tiers.
- Réexaminez la validation si une condition importante du lancement change.
- Ne remplacez pas la confirmation des conditions propres au marché concerné par des informations générales.
Questions fréquentes
La couverture annoncée confirme-t-elle que je peux envoyer des SMS A2P à tous les opérateurs d’un pays ?
Non. La couverture annoncée ne prouve pas à elle seule qu’il existe une connectivité active pour chaque opérateur, chaque expéditeur et chaque cas d’usage, et ne garantit pas la livraison. Confirmez les détails pertinents et, le cas échéant, effectuez des tests contrôlés avant la mise en production.
Puis-je utiliser le même Sender ID dans plusieurs pays ?
Il est préférable de ne pas le supposer. Les éléments disponibles ne permettent pas de confirmer les exigences propres à chaque marché, opérateur ou type de trafic. Renseignez-vous sur les conditions auprès des sources officielles pertinentes et des interlocuteurs responsables de la connexion.
Un DLR confirme-t-il que le message est arrivé sur le téléphone de l’utilisateur ?
Un DLR est un statut rapporté par la chaîne de messagerie, dont la signification dépend de l’implémentation. À lui seul, il ne prouve pas que l’utilisateur a vu le message et n’équivaut pas nécessairement à une vérification indépendante de sa réception sur l’appareil.
Quel seuil de livraison dois-je utiliser pour approuver chaque marché ?
Les éléments disponibles ne permettent pas de définir un seuil universel. Définissez des critères mesurables avec vos équipes et le fournisseur, adaptés au cas d’usage, au volume de test et aux preuves réellement recueillies.
Que doit contenir le registre de lancement ?
À titre de proposition, il peut inclure le périmètre par pays et par opérateur, le cas d’usage, les expéditeurs, les sources et les dates, les conditions de connectivité, la configuration testée, les résultats, les statuts des DLR, les points en attente, les responsables et les décisions d’approbation ou de suspension.
Sources consultées
- 3GPP specifications3GPP
- ITU-T E.164International Telecommunication Union
- GSMA resourcesGSMA